Linux/AM3352: AM3352 FTP download crc issue

Hi user3434218,

Could you give more detailed description of your environment and what you are doing step by step?
Do you observe the issue on every FTP download at same packet or only sometimes?

Regards,
Tsvetolin Shulev

Part Number: AM3352

Tool/software: Linux

Using zImage compiled from ti-processor- SDK -linux-am335x-evm-05.01.00.11, ping is ok, but the tftp sends packets with crc error.

The dts as follow:

cpsw_default: cpsw_default {
pinctrl-single,pins = <
/* Slave 1 */
AM33XX_IOPAD(0x914, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txen.rgmii1_tctl */
AM33XX_IOPAD(0x918, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mii1_rxdv.rgmii1_rctl */
AM33XX_IOPAD(0x91c, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd3.rgmii1_td3 */
AM33XX_IOPAD(0x920, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd2.rgmii1_td2 */
AM33XX_IOPAD(0x924, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd1.rgmii1_td1 */
AM33XX_IOPAD(0x928, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mii1_txd0.rgmii1_td0 */
AM33XX_IOPAD(0x92c, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mii1_txclk.rgmii1_tclk */
AM33XX_IOPAD(0x930, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mii1_rxclk.rgmii1_rclk */
AM33XX_IOPAD(0x934, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mii1_rxd3.rgmii1_rd3 */
AM33XX_IOPAD(0x938, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mii1_rxd2.rgmii1_rd2 */
AM33XX_IOPAD(0x93c, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mii1_rxd1.rgmii1_rd1 */
AM33XX_IOPAD(0x940, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mii1_rxd0.rgmii1_rd0 */
>;
};

&mac {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_sleep>;
status = "okay";
};

&davinci_mdio {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
status = "okay";
};

&cpsw_emac0 {
phy_id = <&davinci_mdio>, <0>;
phy-mode = "mii";
};

Input command in shell(board ip 192.168.80.159, serverip 192.168.80.65):
tftp -gr aaa.txt 192.168.80.65
The wireshark capture packets with crc error.Maybe only the 64 bytes packets with crc error.

In tftp code , some code as " (void) sendto(f, ackbuf, size, 0, (struct sockaddr *)&peeraddr, sizeof(peeraddr));",
when the size is <= 18, it generates a crc error frame; when the size is > 18 , the ethernet generates a normal frame.
The tftp code is "tftp-hpa-0.40".
Please help me. Thank you very much.

In patchwork.kernel.org/.../, Grygorii Strashko fix the min eth packet size bug.
Now CPSW driver configures min eth packet size to 60 octets (ETH_ZLEN)
which works in most of cases, but when port VLAN is configured on some
switch port, it also can be configured to force all egress packets to be
VLAN untagged. And in this case, CPSW driver will pad small packets to 60
octets, but final packet size on port egress can became less than 60 octets
due to VLAN tag removal and packet will be dropped.

Otherwise, In linux kernel, drivers/net/ethernet/ti/cpsw.c #define CPSW_MIN_PACKET_SIZE 60//(VLAN_ETH_ZLEN)
When I do this changes, the tftp works good.
But I still need to enable vlan for using dual mac., what should I do? Please help me.

We added some information for this issue，please help ，Thanks a lot！

Hi,

Are you using the cpsw in dual mac mode or switch mode?

Is there a reason why is the packet size so small on a tftp transfer? Has the tftp client been modified?

Best Regards,
Schuyler

I am using the cpsw in singel mac mode.

I don't modify the tftp client code.I just used it to test.

Thanks for your reply.
when "sendto" size is <= 18, it generated a crc error frame; when the size is > 18 , the ethernet generated a normal frame.
This time, I used smartbits to capture the packets.

Hi,

Currently I am out of the office and expect to return late this coming week, I will investigate further. Please keep in mind that this issue may be beyond what TI does for driver support. If the CPSW driver is sending and receiving packets then the driver is functioning correctly. The packet formation is done by the application being used. In this case you are using a tftp application, I would recommend taking a look at the application to see if there is some limitation on packet size. Which tftp app are you using?

Best Regards,
Schuyler

The tftp app is "tftp-hpa-0.40". The problem is not resolved. Can you give me any other advice？

Hi,

TI provides tftp as part of the busybox configuration in the SDK file system, this is just a simple tftp client. Did you add the tftp-hpa daemon to your file system? The tftp-hpa that you are using is a daemon that TI currently does not add or support.

To verify if I see the issue that you are reporting I used the pre-built images of the same version of the TI SDK that you are using which is 5.01.00.11 and I am able to tftp files from a server that are less that 18 bytes in size. I did not see any issues with transfer. Wireshark showed 63 bytes on the wire on the small file. I also tried a larger file and I am not seeing the issues on Wireshark and both tftp transfer completely successfully and the files were intact.

For TI to support this request the transfer issue has to be isolated to the CPSW driver and a sequence I can reproduce here on a TI EVM.

An earlier post in the thread had this statement:
"input command in shell(board ip 192.168.80.159, serverip 192.168.80.65):
tftp -gr aaa.txt 192.168.80.65"

Based on that statement I want to make sure I understand the direction of transfer that you are doing. Are you transferring files from a Linux PC to the AM3352?

Besides the capture you posted of wireshark reporting an error, are the files transferring? If not could you post the error that you are seeing on the console?

The kernel that you are using, other than the reverted the patch that mentioned are there any other kernel changes?

Also could you please post the results of the following commands executed on the console of the AM3352:
- which tftp
- ls -la <on the string returned from that command>

Best Regards,
Schuyler

     Thanks for your reply.

      I used  tftp client of the busybox , it had the problem.So, I downloaded the "tftp-hpa" source code, compiled it and add to the filesystem. But the  tftp-hpa also have the prolem.Finally, I found the problem appeared when  the "sendto" size < 18. The linux kernel config file and dts as follow. And I add vlan support to the kernel and dual mac support in the dts. dts_defconfig.zip

Hi,

Thanks for sending the kernel config and the DTS file. I compared the config you attached and the one from the SDK, there are a couple of differences around the VLAN configs as you pointed out. The other differences should not impact the network such as touchscreen and spi.

Currently I am not able to reproduce the probelm on a TI EVM. I will not be able to assist unless I can. Do you have a TI EVM that you could try your test with the binaries and filesystem that ship with the SDK?

I noticed that you have dual mac enabled on your platform. Could you please post the output of ifconfig -a from the console on your platform?

Best Regards,
Schuyler

I don't have the evm demo. My board is our company's product refer to the evm design. I need to use 4 uarts and 2 mii. Using the dual mac ,the vlan must be enable.
The ifconfig -a :
[root@ERCW ~]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 8C:04:20:00:00:01
inet addr:192.168.80.140 Bcast:192.168.80.255 Mask:255.255.255.0
inet6 addr: fe80::8e04:20ff:fe00:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3450 errors:0 dropped:20 overruns:0 frame:0
TX packets:173 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:298737 (291.7 KiB) TX bytes:14188 (13.8 KiB)
Interrupt:47

eth1 Link encap:Ethernet HWaddr A8:1B:6A:2E:9F:80
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Hi Schuyler,
Thanks for your help.
Earlier in the thread , I compared the packets between "uboot tftp" and "filesystem tftp", the "uboot tftp" packets captured by the wireshark is good no FCS error.The only way to explain the problem is the kernel cpsw driver may not add crc correctly when the packet size if smaller than 18. So , I think it's a cpsw driver's problem, when the packet size is too small , the FCS value is filled with 0 without recalculating.