LAN/NIC problem

[stepw]

What is the difference between the HW method and the SW patch ?

What we are trying to do is to enable only the Tx-delay and to disable ONLY the Rx-delay.  Both approaches are a hardware solution ;  one sets the GMAC register with a program call ( this uses the longsleep kernel patch to achieve the hardware result ) , and the other uses a physical resistor on the board to 'pull-down' the line to ground which will also afffect the same hardward change -- namely , the Rx-delay will be disabled  and only the Tx-delay will be enabled. 

This either works or it doesn't.  It is sad to hear that register setting is not working for people;  I am preparing to implement the resistor fix on my ubuntu board ( my non working board );  I'll be reporting back here with the results soon.  In the mean time it would be interesting to note which ones ( if any ) the register setting to disable the Rx-delay is actually working in the field. 

Twleve out of twelve boards were 'fixed' in the lab by setting the register;  so something is 'off' in the field. Just a note,  setting Rx-delay = 0  does not work since that setting still results in a 2ns delay regardless;  the Rx-delay actually has to be disabled.

It's actually PHY register, not GMAC register. It's controlled by GMAC via MII though.

BTW, it looks like "magic" CONFREG value 0xd591 disables BOTH TX and RX delay; per RTL8211E datasheet bit 1 controls TX delay state and bit 2 controls RX delay state and 0xd591 disables both by writing zero to those bits. Interestingly, datasheet defines only 9 bits (corresponding to 9 CONFIG pins on the PHY IC), but upper byte is also modified beyond its lowest bit when CONFREG is changed in longsleep's patch (which is ultimately supplied by Pine64 engineering). 

If only bits 1 and 2 are modified in the CONFREG, it doesn't make any difference in terms of Gigabit performance on my Pine64. So there seems to be some significance behind changes in (undocumented) upper byte of CONFREG or bits other than 1 and 2 of the lower byte.

It would be great if Pine64 could disclose specific details of what this CONFREG change achieves, beyond sharing the sequence of MII register writes which is expected to fix the issue. 

OK - I think in my case this is the same issue which is being exhibited in a different way.

If I connect directly from my laptop to my main router wirelessly and ping the pine64 (which is connected to the router via ethernet and configured to run at 10/100mbs) I get packet loss of about 5%.

However, if I introduce an extra 'hop' by ensuring the laptop connects to a wireless extender and repeat the test, then I do not seem to get any packet loss so far.

I think that the extra delay introduced by the wireless extender is masking the problem...?

It's probably best to test from a directly connected wired device rather than a host multiple wired/wireless segments away...