11-02-2016, 04:43 PM
(11-01-2016, 09:16 PM)stepw Wrote: Wow, 0x28 PHY/MII register doesn't even exist, so phy_write(phydev, 0x28, 0xd591);//only enable TX. call is not validSorry, should be 0x1C which is 28.
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