LAN/NIC problem

[waldo]

Doesn't look like slave/master role is of any impact on RTL8211E PHY. I can force slave or master mode on the NIC of the connected PC and PINE64 PHY reports corresponding opposite role, but packet loss persists when pinging from PINE64 to the connected device. Forcing role on PINE64 PHY also results in correct role on both sides, also of no effect on the problem.

1. PINE64 - Auto mode (PHY reg 0x9 = 0x0300), PC - Auto mode
PINE64 PHY reg 0xA = 0x3800 = Gigabit Slave
11 packets transmitted, 8 received, 27% packet loss, time 9999ms

2. PINE64 - Auto mode (PHY reg 0x9 = 0x0300), PC - Slave mode
PINE64 PHY reg 0xA = 0x7800 = Gigabit Master
14 packets transmitted, 9 received, 35% packet loss, time 13005ms

3. PINE64 - Master mode (PHY reg 0x9 - 0x1A00), PC - Slave mode
PINE64 PHY reg 0xA = 0x7800 = Gigabit Master
14 packets transmitted, 10 received, 28% packet loss, time 13008ms

4. PINE64 - Slave mode (PHY reg 0x9 - 0x1200), PC - Slave mode
PINE64 PHY reg 0xA = 0x0000 = Master/Slave fault, not capable of 1Gbps, up at 100Mbps
46 packets transmitted, 46 received, 0% packet loss, time 45001ms

5. PINE64 - Slave mode (PHY reg 0x9 - 0x1200), PC - Master mode
PINE64 PHY reg 0xA = 0x3800 = Gigabit Slave
13 packets transmitted, 11 received, 15% packet loss, time 12004ms

6. PINE64 - Slave mode (PHY reg 0x9 - 0x1200), PC - Auto
PINE64 PHY reg 0xA = 0x3800 = Gigabit Slave

19 packets transmitted, 6 received, 68% packet loss, time 18004ms

smart thinking
thanks for busting my dreams

Well, that takes us back to the fact that is seems these boards realy ARE broken from a HW point of view.
I'm starting to question the sanity of keeping production going at this point .... shouldn't this get fixed first ?


//waldo

[jandvs]

I received a replacement board for the one I sent to TM Lim a couple of weeks ago. This one works perfect. Full GBe. No packet loss.

Mark, I mentioned to you a few weeks ago about the crystal on my old board was upside down compared to the one on my friends working board. I noticed that this one has it mounted like on my friends board. Not like it was on my defective board. Still have no idea if that has anything to do with the cost of tea in china (or anything actually relevant).

[amc2012]

I also finally got a working one. The first replacement also suffered from the issue, but the most recent one has GbE working great.

What is the "crystal?" Going to look at some pics of my old board compared to this one.

[jandvs]

I also finally got a working one. The first replacement also suffered from the issue, but the most recent one has GbE working great.

What is the "crystal?" Going to look at some pics of my old board compared to this one.

It's a little silver oval in the center of the board, just above the A64 processor.  I have no idea if the orientation of it makes a lick of difference.  It's just an observation on my board it was mounted the same direction as the processor.  On my friends and another working board, it's upside down compared to the processor.  This new board also has it upside down compared to the processor.

[pfeerick]

I also finally got a working one. The first replacement also suffered from the issue, but the most recent one has GbE working great.

What is the "crystal?" Going to look at some pics of my old board compared to this one.

It's a little silver oval in the center of the board, just above the A64 processor.  I have no idea if the orientation of it makes a lick of difference.  It's just an observation on my board it was mounted the same direction as the processor.  On my friends and another working board, it's upside down compared to the processor.  This new board also has it upside down compared to the processor.

If it is just a crystal, orientation (left to right, right to left) doesn't make any difference - they are not a polarised component.

[androsch]

I also finally got a working one. The first replacement also suffered from the issue, but the most recent one has GbE working great.

Also received my replacement board for the bad one sent to tllim some weeks ago for testing.

BUT, bad news, new board has the same problems regarding GbE as before, so no improvement :-(

Just exchanged the board (using same PSU, SD card and cable as with the working developer board from tkaiser) and speed was dropping to nearly zero.

Putting it to a fixed 100mbps port was stable and reliable as before, so FastEthernet is fine, GbE not working.

Hope tllim and the hardware guys can work out the real problem with our bad boards (they should have a sufficient amount of that now) and solve this issue...

[waldo]

Apparently ... the RX/TX vallues are under scrutiny ... again ...
has anyone ever tried the script i wrote to see if it becomes better for any of you ?
I only went downhill for me ....

Hey all, I found this thread while searching for ways to get GigE working on my Pine64 2GB. I'm not quite sure I have the latest longsleep kernel, but I did just install the most recent one I could find the other day:

Code:

kevin@pine64:~$ uname -a
Linux pine64 3.10.102-2-pine64-longsleep #66 SMP PREEMPT Sat Jul 16 10:53:13 CEST 2016 aarch64 aarch64 aarch64 GNU/Linux

I added the network tuning script to /etc/rc.local, but the improvement was very minimal. Using iperf I see bandwidths rarely topping 4 Mbits/sec. If I run "sudo ethtool -s eth0 speed 100 duplex full" or plug into a 10/100 switch, I very consistently get 92+ MBits/sec.

I can live with this, but I intended to use my Pine64 as a file server, so it is falling a little short. Am I missing something?

longsleep, thank you for all your hard work on this. It's really impressive.

We recently make some good progress on the gigabit connection issue (packet loss) by tuning the GbE TX/RX delay. We will release the Android build first on few hours time. If the improvement shows positive, we will propagate to Linux build.

[tllim]

Apparently ... the RX/TX vallues are under scrutiny ... again ...
has anyone ever tried the script i wrote to see if it becomes better for any of you ?
I only went downhill for me ....

Hey all, I found this thread while searching for ways to get GigE working on my Pine64 2GB. I'm not quite sure I have the latest longsleep kernel, but I did just install the most recent one I could find the other day:

Code:

kevin@pine64:~$ uname -a
Linux pine64 3.10.102-2-pine64-longsleep #66 SMP PREEMPT Sat Jul 16 10:53:13 CEST 2016 aarch64 aarch64 aarch64 GNU/Linux

I added the network tuning script to /etc/rc.local, but the improvement was very minimal. Using iperf I see bandwidths rarely topping 4 Mbits/sec. If I run "sudo ethtool -s eth0 speed 100 duplex full" or plug into a 10/100 switch, I very consistently get 92+ MBits/sec.

I can live with this, but I intended to use my Pine64 as a file server, so it is falling a little short. Am I missing something?

longsleep, thank you for all your hard work on this. It's really impressive.

We recently make some good progress on the gigabit connection issue (packet loss) by tuning the GbE TX/RX delay. We will release the Android build first on few hours time. If the improvement shows positive, we will propagate to Linux build.

Our experience is need to disable the RX delay, this can be implement thru hardware method: discover the LED2_RXDLY line pull up resistor to pul down or software method, program the RX control register: phy_write(phydev, 0x28, 0xd591);//only enable TX.

Somehow, setup the RX delay to 0 not same as disable RX delay. This finding also puzzle me.

... TL Lim

[androsch]

Can someone give a instruction for noobs please?
Maybe longsleep with a new kernel or a detailed setup for the dtb-file?

Edit: Sorry, just noticed longsleep already provided a new kernel, thanks to him, will check out later.
Thanks to Simon, great job!

[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