Re: Aquantia PHY in OCSGMII mode?

[Alexander Wilhelm <alexander.wilhelm@westermo.com>]

Am Wed, Aug 06, 2025 at 05:58:56PM +0300 schrieb Vladimir Oltean:
> On Tue, Aug 05, 2025 at 02:44:15PM +0200, Alexander Wilhelm wrote:
> > Patch is applied. Here are the registers log:
> > 
> >     user@host:~# 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@host:~# 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
> 
> Sorry, I am not fluent enough with the Aquantia PHYs to be further
> helpful here.
> 
> I have made a procedural mistake by suggesting you to print select
> fields of the Global System Configuration registers instead of the raw
> register values. I am unable to say with the required certainty whether
> the configuration for 100M and 1G is identical or not. The printed
> fields are the same, however there could still be differences in the
> unprinted bits (looking at bit 12 'Low Delay Jitter'). That's something
> you should explore further.
> 
> About MAC RX counters not increasing at all. The mEMAC has a catch-all
> RERR counter which increments for each frame received with a wider
> variety of errors (except for undersized/fragment frames):
> - FIFO overflow error
> - CRC error
> - Payload length error
> - Jabber and oversized error
> - Alignment error (if supported)
> - Reception of PHY/PCS error indication
> The structured ethtool statistics API doesn't seem to have a counter for
> received frame errors in general, only for specific errors. So I didn't
> export it in the patch I sent. It's possible that this counter is
> incrementing (but the more specific RFCS/RALN/... counters apparently not).
> 
> In any case, the T1023 host configuration is literally unchanged from
> 1G to 100M, so I am suspecting a misconfiguration in the Aquantia
> provisioning somewhere. Maybe an FAE or AE from Marvell can help you
> further with this issue.
> 
> If you do contact them, please also request them to fix the discrepancy
> where the Global System Configuration register for speed 2500 has
> "autoneg 1", but all the other speeds have "autoneg 0" for the same
> SerDes mode 4. It is precisely this concern that I was expressing to
> Russell that makes it difficult to implement .inband_caps() based on
> reading PHY registers.

Hi Vladimir,

Now that I have 1G/2.5G working, I’ll be able to run some additional tests with
the device. I’ll revisit the 100M topic later and analyze it more thoroughly. I
suspect that some register settings in U-Boot might be causing issues when the
PHY is initialized again in the kernel.

I truly appreciate your detailed support, it has been incredibly helpful in
moving things forward.


Best regards
Alexander Wilhelm