I am trying to get hardware to work which replaced the Aquarius PHY of the nvethernet NIC with a LAN966x switch. This works with a recent 6.x kernel. For example with 6.13.8.
Almost the same code using a back ported lan966x driver and the 5.15.136-tegra kernel. We have a number of drivers that we can’t easily move to another kernel like the 6.8.x kernels from more recent jetpacks.
The primary symptom: DMA SWR never self-clears
On every failed test the EQOS MAC shows:
mmc_tx_framecount_gb: 0
mmc_rx_framecount_gb: 0
DMA_BMR[0] = 1 (Software Reset bit stuck at 1)
The DMA internal state machine is in permanent reset. Any
packets submitted to the DMA ring sit there untouched. This is
the root cause of the NIC not functioning.
Instead of using a modified version of nvethernet we also tested with a back port of stmmac + dwmac-dwc-qos-eth.
The SWR (DMA Software Reset) bit in DMA_BMR at offset 0x1000
of the Tegra234 EQOS never self-clears in this hardware/firmware
environment. This is true regardless of:
-
which driver is used (nvethernet, upstream stmmac) –
-
whether MAC_1US_TIC_CNTR is programmed –
-
whether MAC_CTRL_REG has PS/FES/DM set –
-
how the clocks are sequenced –
-
how long we poll –
-
whether
reset_control_reset/deassert/assert+deassert
is used – -
whether the RGMII RXC clock from the link partner is active at
the moment of reset.
The same hardware works on kernel 6.13.8 with the same
drivers, and works on kernel 5.15 when connected to an Aquantia
PHY instead of the lan966x fixed-link. This narrows the cause
to something that the 5.15 kernel/firmware environment provides
differently from 6.13.8, and that a real PHY (with live clocks
from first power-up) masks but a fixed-link cannot.
Questions: Is this a know issue with the 5.15 kernel? Is there a patch, the Tegra 234 driver comes to mind that can make the SWR (DMA Software Reset) work with this kernel or are we forced to upgrade to a more recent version of jetpack with a more recent kernel?