Skip to main content
Associate
November 13, 2025
Solved

Packet Loss with AR8031 PHY on STM32MP1 - Direct Connection to Linux Host

  • November 13, 2025
  • 1 reply
  • 173 views

Hello everyone,

I'm experiencing an issue with network packet loss in a setup using the AR8031 PHY with an STM32MP1 system and would appreciate any insights or suggestions.

Problem Description:

  • Significant (60-90%) packet loss when STM32MP1 board is directly connected to a Linux host via Ethernet

  • No packet loss when the same board is connected through an Ethernet switch

  • Issue occurs consistently with direct host connections

Tested/Verified so far:

  • Multiple known-good Ethernet cables (CAT5e/CAT6)

  • Different Linux hosts

  • Link speed and duplex settings (100M/1G, full/half duplex), 100M works fine with no packet loss
  • Enable/disable various PHY driver quirks (qca,disable-smarteee, qca,disable-hibernation-mode, qca,clk-out-strength, qca,keep-pll-enabled, qca,smarteee-tw-us-1g)

Device Tree Snippet:

&ethernet0 { 
 status = "okay"; 
 pinctrl-0 = <&ethernet0_rgmii_pins_a>; 
 pinctrl-1 = <&ethernet0_rgmii_sleep_pins_a>; 
 pinctrl-names = "default", "sleep"; 
 phy-mode = "rgmii-id"; 
 max-speed = <1000>; 
 phy-handle = <&phy0>; 
 nvmem-cells = <&ethernet_mac_address>; 
 nvmem-cell-names = "mac-address"; 
 phy-supply = <&eth_reg>; 
 st,eth-clk-sel; 
 
 mdio0 { 
 #address-cells = <1>; 
 #size-cells = <0>; 
 compatible = "snps,dwmac-mdio"; 
 phy0: ethernet-phy@0 { 
 reg = <0>; 
 qca,clk-out-frequency = <125000000>; 
 qca,disable-smarteee; 
// qca,disable-hibernation-mode; 
// qca,clk-out-strength = <0>; 
// qca,keep-pll-enabled; 
// qca,smarteee-tw-us-1g = <128>; 
// qca,smarteee-tw-us-100m = <24>; 
 }; 
 }; 
}; 

Questions:

  1. Has anyone encountered similar issues with AR8031 PHY on STM32MP1?

  2. Are there specific device tree properties for AR8031 that I might be missing?

  3. Any known workarounds/specific settings for direct host connections?

Additional Info:

  • Kernel version: 6.1.28

  • ST OpenSTLinux 6.1

 

Best answer by DmitryKon

For history:

The issue is fixed by this commit in https://github.com/STMicroelectronics/linux.git:

commit 8efbdbfa99381a017dd2c0f6375a7d80a8118b74
Author: Marek Vasut <marex@denx.de>
Date: Sun May 7 01:58:45 2023 +0200

net: stmmac: Initialize MAC_ONEUS_TIC_COUNTER register

Initialize MAC_ONEUS_TIC_COUNTER register with correct value derived
from CSR clock, otherwise EEE is unstable on at least NXP i.MX8M Plus
and Micrel KSZ9131RNX PHY, to the point where not even ARP request can
be sent out.

1 reply

DmitryKonAuthorBest answer
Associate
December 1, 2025

For history:

The issue is fixed by this commit in https://github.com/STMicroelectronics/linux.git:

commit 8efbdbfa99381a017dd2c0f6375a7d80a8118b74
Author: Marek Vasut <marex@denx.de>
Date: Sun May 7 01:58:45 2023 +0200

net: stmmac: Initialize MAC_ONEUS_TIC_COUNTER register

Initialize MAC_ONEUS_TIC_COUNTER register with correct value derived
from CSR clock, otherwise EEE is unstable on at least NXP i.MX8M Plus
and Micrel KSZ9131RNX PHY, to the point where not even ARP request can
be sent out.