[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aJH8n0zheqB8tWzb@FUE-ALEWI-WINX>
Date: Tue, 5 Aug 2025 14:44:15 +0200
From: Alexander Wilhelm <alexander.wilhelm@...termo.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: Aquantia PHY in OCSGMII mode?
Am Tue, Aug 05, 2025 at 01:20:56PM +0300 schrieb Vladimir Oltean:
> On Tue, Aug 05, 2025 at 09:59:57AM +0200, Alexander Wilhelm wrote:
> > I have a ping running in the background and can observe that MAC frames and
> > TX-RMON packets are continuously increasing. However, the PHY statistics remain
> > unchanged. I suspect the current SGMII frames originate from U-Boot, as I load
> > the firmware image via `netboot`. These statistics were recorded at 2.5G speed,
> > but the same behavior is also visible at 1G.
> >
> > Do you think the issue still lies within the MAC driver, or could it be related
> > to the Aquantia driver or firmware?
>
> So the claim is that in U-Boot, the exact same link with the exact same
> PHY firmware works, right? Yet in Linux, MAC transmit counters increase,
> but nothing comes across on the PHY side of the MII link? What about
> packets sent from the link partner (the remote board connected to the PHY)?
> Do packets sent from that board result in an increase of PHY counters,
> and MAC RX counters?
>
> For sure this is the correct port ("ffe4e6000.ethernet" corresponds to fm1-mac4,
> port name in U-Boot would be "FM1@...EC4")? What SoC is this on? T1 something?
> What SRDS_PRTCL_S1 value is in the RCW? I'd like to trace back the steps
> in order to establish that the link works at 2.5G with autoneg disabled
> on both ends. It seems to me there is either a lack of connectivity
> between the MAC used in Linux and the PHY, or a protocol mismatch.
Hi Vladimir,
thank you, you just solved my problem. I indeed have made an error in the DTS
file by setting the wrong MAC.
I'm using the T1023E CPU with e5500 core. For the SRDS_PRTCL_S1 value I set
0x135. That corresponds to the following:
* A: Aurora (5G/2.5G)
* B: sg.m3 (2.5G)
* C: PCIe2 (5G/2.5G)
* D: PCIe1 (5G/2.5G)
My PHY is directed to the `FM1@...EC3`, MAC3 instead of previously configured
MAC4. I fixed it by using ethernet `eth@...4e4000`. Now I have ping in both
directions with 2.5G and 1G speed settings. I cannot test 10M, because my host
does not support it. And 100M still does not work, as it does not work in U-Boot
as well.
> Could you please also apply this PHY debugging patch and let us know
> what the Global System Configuration registers contain after the
> firmware applies the provisioning?
Patch is applied. Here are the registers log:
user@...t:~# logread | grep AQR115
Aquantia AQR115 0x0000000ffe4fd000:07: Speed 10 SerDes mode 4 autoneg 0 training 0 reset on transition 0 silence 0 rate adapt 2 macsec 0
Aquantia AQR115 0x0000000ffe4fd000:07: Speed 100 SerDes mode 4 autoneg 0 training 1 reset on transition 0 silence 1 rate adapt 2 macsec 0
Aquantia AQR115 0x0000000ffe4fd000:07: Speed 1000 SerDes mode 4 autoneg 0 training 1 reset on transition 0 silence 1 rate adapt 2 macsec 0
Aquantia AQR115 0x0000000ffe4fd000:07: Speed 2500 SerDes mode 4 autoneg 1 training 1 reset on transition 0 silence 1 rate adapt 0 macsec 0
Aquantia AQR115 0x0000000ffe4fd000:07: Speed 5000 SerDes mode 0 autoneg 0 training 0 reset on transition 0 silence 0 rate adapt 2 macsec 0
Aquantia AQR115 0x0000000ffe4fd000:07: Speed 10000 SerDes mode 0 autoneg 0 training 0 reset on transition 0 silence 0 rate adapt 0 macsec 0
fsl_dpaa_mac ffe4e4000.ethernet eth0: PHY [0x0000000ffe4fd000:07] driver [Aquantia AQR115] (irq=POLL)
While 100M transfer, I see the MAC TX frame increasing and SGMII TX good frames
increasing. But the receiving frames are counted as SGMII RX bad frames and MAC
RX frames counter does not increase. The TX/RX pause frames always stay at 0,
independently whether ping is working with 1G/2.5G or not with 100M. Do you have
any idea here?
user@...t:~# ethtool -S eth0 --groups eth-mac eth-phy eth-ctrl rmon | grep -v ': 0' && ethtool --phy-statistics eth0 | grep -v ': 0' && ethtool -I --show-pause eth0
Standard stats for eth0:
eth-mac-FramesTransmittedOK: 529
eth-mac-FramesReceivedOK: 67
eth-mac-OctetsTransmittedOK: 79287
eth-mac-OctetsReceivedOK: 9787
eth-mac-MulticastFramesXmittedOK: 43
eth-mac-BroadcastFramesXmittedOK: 451
eth-mac-MulticastFramesReceivedOK: 32
eth-mac-BroadcastFramesReceivedOK: 1
rx-rmon-etherStatsPkts64to64Octets: 3
rx-rmon-etherStatsPkts65to127Octets: 42
rx-rmon-etherStatsPkts128to255Octets: 18
rx-rmon-etherStatsPkts256to511Octets: 4
tx-rmon-etherStatsPkts64to64Octets: 5
tx-rmon-etherStatsPkts65to127Octets: 385
tx-rmon-etherStatsPkts128to255Octets: 26
tx-rmon-etherStatsPkts256to511Octets: 113
PHY statistics:
sgmii_rx_good_frames: 21149
sgmii_rx_bad_frames: 176
sgmii_rx_false_carrier_events: 1
sgmii_tx_good_frames: 21041
sgmii_tx_line_collisions: 1
Pause parameters for eth0:
Autonegotiate: on
RX: off
TX: off
RX negotiated: on
TX negotiated: on
Statistics:
tx_pause_frames: 0
rx_pause_frames: 0
Best regards
Alexander Wilhelm
Powered by blists - more mailing lists