LAN/NIC problem

[stepw]

Wow, 0x28 PHY/MII register doesn't even exist, so  phy_write(phydev, 0x28, 0xd591);//only enable TX. call is not valid

According to longsleep's driver patch, the following calls are actually used:

Code:

+ phy_write(phydev, 0x1f, 0x0007);//sel ext page
+ phy_write(phydev, 0x1e, 0x00a4);//sel page 164
+ phy_write(phydev, 0x1c, 0xd591);//only enable TX
+ phy_write(phydev, 0x1f, 0x0000);//sel page 0

That sequence is more feasible and does appear to improve TX performance, but RX is still garbage on my Pine64.

My iperf3 tests under armbian:

100Mbps link:
Pine64->PC
TCP: 96Mbps
UDP: 96Mbps generated 96Mbps received

PC->Pine64
TCP: 96Mbps
UDP: 96Mbps generated 96Mbps received


1Gbps link, with RX/TX delay (e.g. CONFREG = 0x8577 = 0b1000010101110111)
Pine64->PC
TCP: 500kbps
UDP: 670Mbps generated 50Mbps received

PC->Pine64
TCP: 1.16kbps
UDP: 900Mbps generated 0kbps received


1Gbps link, without RX/TX delay (e.g. CONFREG = 0xd591 = 0b1101010110010001)
Pine64->PC
TCP: 500Mbps
UDP: 690Mbps generated 690Mbps received

PC->Pine64
TCP: 1.5Mbps
UDP: 900Mbps generated 20Mbps received


Interestingly, some of the changed CONFREG bits are not even in Realtek's data sheet. Changing TX/RX delay (bits 1 and 2) alone doesn't make a difference. This still doesn't look like something that can be fixed in software