PatchTrack

From: Heiko Stuebner <heiko@...> Date: Wed, 24 Sep 2025 22:35:06 +0200

Commit-Message

While I want to remember that the dwmac on the TS433 was working at some point, it seems I had my network always connected to the 2.5G nic after that "point". And testing now revealed that the gmac does not actually manages to transfer data. Currently the gmac is set to rgmii-id with no rx-/tx-delay values set which makes the driver use default values. Setting the delays to 0 also does not provide a working interface. The vendor kernel is running with phy-mode set to rgmii and delays of tx_delay = 0x3c, rx_delay = 0x2f As Andrew points out often, those delay values "are magic" and rgmii-id should definitly be used "with small values" for delays, if really needed. The Rockchip vendor-kernel actually contains additional code in the dwmac driver to use the loopback function of a phy to find a window of usable delay values. Code can be found for example on [0] and the process is described in a document called "Rockchip GMAC RGMII Delayline Guide" which has made its way onto the internet in a lot of places [1]. So I used this process, with the interface set to rgmii-id to get values for this mode, which are in face lower than the ones for rgmii with tx_delay = 0x21, rx_delay = 0x15 and results in a working interface on the dwmac. [0] https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr6.1/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c [1] https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf Cc: Andrew Lunn <andrew@...> Signed-off-by: Heiko Stuebner <heiko@...>

Patch-Comment

arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts | 2 ++ 1 file changed, 2 insertions(+)

Statistics

• 2 lines added
• 0 lines removed

Changes