Fixing Unstable Gigabit Ethernet on ROCK64 v2

Important: This hardware modification applies specifically to ROCK64 revision 2.0 boards affected by unstable Gigabit Ethernet. It involves soldering very small components and can permanently damage the board. Check your board revision before attempting it.

I bought three 4 GB ROCK64 boards for a small home Kubernetes cluster. They were fast, quiet and generally reliable—which is an admirable combination in both computers and people.

One board, however, behaved differently.

From time to time, the green LED on its Ethernet socket switched off and remained off until the board was restarted. Because the machine otherwise appeared to work, I did not pay much attention to it.

That proved optimistic.

Corrupt Downloads and an Unreliable Node

I was using Ansible to automate the installation of Docker, Kubernetes and the other components required by the cluster. The playbook is still available in my Kubernetes nano-cluster repository on GitHub.

Provisioning worked on two of the ROCK64 boards. The third began hanging or failing while installing Ubuntu packages.

The errors looked like this:

dpkg-deb (subprocess): decompressing archive member:
lzma error: compressed data is corrupt

dpkg-deb: error:
<decompress> subprocess returned error exit status 2

dpkg-deb (subprocess): decompressing archive member:
lzma error: compressed data is corrupt

dpkg-deb: error:
<decompress> subprocess returned error exit status 2

My first suspicion was faulty memory. Corrupt compressed data has a way of pointing accusingly at RAM, storage or both.

After several failed attempts to provision the machine, I concluded that the board probably had a hardware defect and ordered another ROCK64.

Then I found the ROCK64 v2 network issues discussion on the PINE64 forum.

The symptoms were remarkably familiar: unreliable Gigabit Ethernet, checksum errors and a suspicious difference between ROCK64 revisions 2 and 3.

The ROCK64 v3 Ethernet Change

PINE64’s ROCK64 version 3 change notice describes an Ethernet PHY configuration change intended to reduce packet loss on Gigabit Ethernet.

The components involved are close to the RTL8211F Ethernet transceiver.

The wording in the change notice is somewhat confusing. Comparing the actual revision 2 and revision 3 schematics provides a clearer explanation.

Comparing the ROCK64 v2 and v3 Schematics

In the ROCK64 v2 schematic:

• CFG_EXT is pulled high.
• CFG_LDO0 is pulled low through R3327.
• CFG_LDO1 is pulled high through R3332.
• R3331, the alternative pull-down position, is marked DNP—“do not populate.”

In the ROCK64 v3 schematic, the arrangement is reversed:

• CFG_EXT remains pulled high.
• CFG_LDO0 remains pulled low.
• R3331 is populated, pulling CFG_LDO1 low.
• R3332 is marked NC and is not fitted.

These two images illustrate the documented electrical difference between the board revisions, but they do not show the physical movement of the resistor on the board.

What the Configuration Change Does

The relevant pins on the RTL8211F are shared between the Ethernet LEDs and hardware-configuration signals:

• LED0/CFG_EXT
• LED1/CFG_LDO0
• LED2/CFG_LDO1

According to the RTL8211F documentation, pulling CFG_EXT high tells the PHY to use an external power source for its RGMII I/O pads.

The values of CFG_LDO1 and CFG_LDO0 then identify the external I/O voltage:

CFG_LDO1 CFG_LDO0

0        0         3.3 V
0        1         2.5 V
1        0         1.8 V
1        1         1.5 V

CFG_LDO1 CFG_LDO0

0        0         3.3 V
0        1         2.5 V
1        0         1.8 V
1        1         1.5 V

On ROCK64 v2, the configuration is 10, selecting 1.8 V.

On ROCK64 v3, it is 00, selecting 3.3 V.

The important change is therefore not to CFG_EXT, which remains high. It is the change to CFG_LDO1: R3332 is removed and R3331 pulls the signal low instead.

The Intended Modification

The proper revision 3-style modification is:

1. Remove the 4.7 kΩ resistor from R3332.
2. Fit a 4.7 kΩ resistor at R3331.

Unfortunately, the original resistor is an 0402 surface-mount component, approximately 1 × 0.5 mm.

I managed to remove it.

Putting it back in the new position was another matter. My soldering equipment, eyesight and remaining optimism were not equal to the task.

Using a Through-Hole Resistor Instead

Because R3331 is simply a pull-down resistor, it does not have to be physically mounted on the original 0402 footprint.

One end must connect to the LED2/CFG_LDO1 signal. The other must connect to ground.

After removing R3332, I soldered a conventional through-hole resistor between:

• The R3332 signal pad nearer the RTL8211F chip
• A verified ground point near the audio socket

I used a 2 kΩ resistor because that was what I had available at the time. It worked on my board, but both the RTL8211F documentation and the ROCK64 v3 schematic specify 4.7 kΩ, so that is the value I recommend.

Do not replace the resistor with a direct connection to ground. The RTL8211F documentation specifies an external pull-high or pull-low resistor for its configuration pins.

I also insulated the exposed resistor leads to prevent them from touching other pads or components.

Testing the Result

After completing the modification, I booted the ROCK64 and repeated the Ansible provisioning process.

This time, the package installation completed successfully. The corrupt downloads disappeared, and the board became usable as the third node in my Kubernetes cluster.

Because the RTL8211F configuration signals share pins with the Ethernet LEDs, changing the resistor straps may also alter the LEDs’ active state or behaviour. That does not necessarily indicate another fault.

This modification fixed my ROCK64 v2 board, but it should not be applied automatically to every unreliable network connection. It is also unnecessary on ROCK64 revision 3 boards, where the revised resistor arrangement is already present.

In this case, the memory and storage were innocent. The culprit was one of the smallest components on the board – which naturally caused one of the largest amounts of swearing.