we are trying to enable Checksum Offload Engine (COE) / IPC Full Offload in our Cyclone V HPS.
Here is what we have done so far:
- Use 32 bytes transmit/receive descriptors and set the ATDS bit of the BUS_MODE register
- Set the IPC bit of the MAC_CONFIG register
- Set the CIC bits to 0x3 in TDES0
But Checksum offload seems to remain disabled because all packets that are transmitted have their IP/TCP/UDP/ICMP checksum cleared to 0, and receive descriptors have their RDES0 bit cleared also.
What did we forget ?
Just to check, can you check these registers if the Rx/Tx Checksum offload is enabled?, rxtyp2coe,rxtyp1coe,txoesel:
It seems that the rxtyp1coe, which is supposed to be the IP Checksum Offload (Type 1) in Rx , is disabled which might be the issue. Is it always disabled? Have you had any chance to enabled it ?
I thought the the HW_Feature register was static and only reporting the implemented hardware feature implemented in the peripheral itself, not depending on its current configuration:
This register indicates the presence of the optional features or functions of the gmac. The software driver can use this register to dynamically enable or disable the programs related to the optional blocks.
So I don't think that the Type 1 offload can be enabled.
Moreover, I did not find an explanation in the datasheet about the difference between type 1 and type 2. Where are they described in the HPS reference manual ?
I apologize, I have checked from the Technical Reference Manual provided in my previous reply, the default bits are suppose that the Type 1 is by default is disabled and only Type 2 and the TX checksum is enabled.
Have you try a reset if this solves the issue? Just for confirmation can you share your kernel version that you are using?
I may need some more time to dig in for more information regarding this issue.
In the meantime, if you could share the status of the checksum offload, you can use the ethtool. eg. if your eth card is called eth0 (confirm by ifconfig command) :
# ethtool -k eth0
Unfortunately, we do not have the documents on third party TCP/IP stack usage using baremetal.
Have you tried contacting the third party company for any further clues?
I have checked data at the input/output of the mac peripheral, so before they are passed from/to the tcp/ip stack. The bad configuration is somewhere in the peripherals configuration.
An idea would be to enable checksum offload on our DE10 demo board running Linux and compare registers values with what we set in our own firmware. How can we enable checksum offload in Linux (Linux image from terrasic) ?
Based on my knowledge, I haven't found any information regarding enabling the checksum offload directly via Linux, have you contacted Terasic directly regarding this issue?
I may need to check the Linux capability if it can enable the checksum offload.