Forums » Software Development »
Very high TX packet loss on gigabit Ethernet
Added by Chris Weinman almost 10 years ago
I've been having trouble getting gigabit Ethernet working on a MitySOM-5CSX dev kit using a preloader, u-boot and linux built as per the instructions at Building_u-Boot_and_Preloader and Yocto_for_MitySOM-5CSX. It works fine with the supplied SD card, and my kernel and filesystem work fine using uboot and the preloader on the supplied SD card.
- The interface rarely gets an IP from DHCP during boot, but will eventually get one.
- Ping shows up to 60% packet loss.
- Pinging another machine running wireshark shows that not every ICMP echo request is received, but the MitySOM module receives every echo response that is sent.
I've found that this can be fixed by tweaking the GTX_CLK pad skew register in the PHY (p24 of the Micrel KSZ9031RNX datasheet). Any value over 0b10001 (+120 ps) seems to work.
I'm having to do this in U-Boot, after the initphy script is run (as this resets the PHY). The micrel-ksz9021-clk-skew U-Boot environment variable doesn't seem to do anything, which I suspect is because the PHY is a 9031 rather than 9021. The txc-skew-ps property of the Ethernet interface in the device tree doesn't help either, which I suspect is because the generic PHY driver is being used instead of the Micrel one ("# CONFIG_MICREL_PHY is not set" in /proc/config.gz).
I'm using the following U-Boot commands to set the register
mii write 0x3 0xd 0x2 mii write 0x3 0xe 0x8 mii write 0x3 0xd 0x4002 mii write 0x3 0xe 0x3e2f
This seems to work, but I'm worried that this is a sign I've missed something in my U-Boot or Linux build/deployment. Has anyone else seen this sort of thing?
Thanks,
Chris
Replies (4)
RE: Very high TX packet loss on gigabit Ethernet - Added by Michael Williamson almost 10 years ago
Hi Chris,
We've had this module deployed on a couple of different designs as well as the DevKits and I don't think we've had to tweak the pad skews and I know that our packet loss was pretty much negligible. Our validation test uses iperf and didn't show this kind of loss, but our factory/production test probably isn't as aggressive a test.
Are these statements true?
- The reference SD card image does not exhibit high packet loss.
- Something with your build (u-Boot, or Preloader, but not the kernel) results in a higher packet loss that can be fixed with tweaking the GTX_CLK pad skew.
You are correct about the micrel-ksz9021-clk-skew variable (as in, that parameter will not get applied to the KSZ9031RNX phys because the PHY ID check actually fails) in u-Boot. We didn't worry about this at the time as it appeared we didn't need to adjust the timing. Sounds like we may be on the edge or something in the newer u-Boot code is altering the pad characteristics here.
Have you changed any of the I/O parameters on the RGMII lines in quartus? (e.g., changed drive strength or added pull-up/down resistors? Not sure if you can mess with that on the HPS pins but looking for anything that might be different).
Do you have more than one board?
-Mike
RE: Very high TX packet loss on gigabit Ethernet - Added by Chris Weinman over 9 years ago
Hi Mike,
I/O parameters turned out to be the problem. They were set to their default values (higher than they should have been). Doing the pin assignments properly seems to have fixed the problem, U-Boot is working without a hitch now.
Thanks,
Chris
RE: Very high TX packet loss on gigabit Ethernet - Added by Michael Williamson over 9 years ago
Hi Chris,
Can you expand a bit? Do you mean the IO bank voltage settings were not correct?
-Mike
RE: Very high TX packet loss on gigabit Ethernet - Added by Chris Weinman over 9 years ago
Hi Mike,
I don't think those pins are associated with an IO bank. In the pin planner the default setting for those pins is the 2.5 V I/O standard, when they should be 1.8 V. Fixing this (and any other pins that were set to their default) has fixed the problem. Running the mitysom_5csx_dev_board_setup.tcl script achieves this. I'm not sure how they got dropped (our project is based on the blank dev kit project provided).
After building the preloader with the new handoff files, everything seems to be working.
Thanks,
Chris
