On Monday, 4 March 2024 14:09:15 CET Andrew Lunn wrote: > > > Andrew already pointed out when I posted the patch introducing the gmac0 > > > node that rgmii-id would be the preferred way to setup things. Back > > > then this didn't happen because this change broke reception of network > > > packets. However this only happend because I didn't have the right phy > > > driver loaded. > > > > It could be that the PHY is strapped to not use its internal RX delay. > > And the PHY has some weird default TX delay, so having the driver > > put some sensible values in is probably better. > > It could also be the bootloader putting odd values into the PHY. > > Anyway, it will work better with the correct PHY, and enable WoL > support. Not sure if this is the right place or way, but here we go... A few days ago on #debian-kernel@OFTC: [28.02 16:35] <ukleinek> u-boot should be out of the game [28.02 16:36] <diederik> I'm not so sure anymore. On Quartz64 Model A and B (rk3566) I had massive packet loss and tracked it down to a change in u-boot [28.02 16:37] <ukleinek> diederik: sounds like the Linux network driver on that machine could do something better [28.02 16:38] <diederik> yeah, probably I reported this about a month ago to Jonas Karlman as I bisected the problem to a change in u-boot: > diederik@bagend:~/dev/u-boot/u-boot$ git bisect bad > 25f56459aebced8e4bb7d01061dcb1b765b197e2 is the first bad commit > commit 25f56459aebced8e4bb7d01061dcb1b765b197e2 > Author: Jonas Karlman <jonas@xxxxxxxxx> > Date: Sun Oct 1 19:17:21 2023 +0000 > > configs: rockchip: Enable ethernet driver on RK356x boards > > Enable DWC_ETH_QOS_ROCKCHIP and related PHY driver on RK356x boards that > have an enabled gmac node. I just checked and both Quartz64 Model A and B have `phy-mode = "rgmii";` and set `tx_delay` and `rx_delay` to some (other) values. Without knowing nor understanding the details, this seem very much related? Cheers, Diederik
Attachment:
signature.asc
Description: This is a digitally signed message part.
