Fixing Rock64 v2 Gigabit Ethernet

Half a year ago I bought three Rock64 (4 GB model) for my home Kubernetes cluster and I was mostly happy with them, they are quick, quiet and reliable. Although, I noticed one issue. From time to time the green LED on the Ethernet socket was switching off and staying off until a reboot. I didn’t pay attention to that since it was not affecting stability or performance, at least that’s what I thought.

Pursuing the opportunity to refresh my Ansible skills, I decided to automate the Kubernetes provisioning and started creating a playbook (you can find it here) and executing it provisioning my nano-cluster using only two of my three Rock64s. Everything was going alright until the final check when I tried to provision all three of them installing Docker, Kubernetes, and some other component. My third SBC started randomly hanging and failing to install Ubuntu packages. When it was an apt package installation failure the error was 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: error processing archive /var/cache/apt/archives/kubectl_1.15.1-00_arm64.deb (--unpack):

I was quite sure that it’s a hardware problem but wasn’t sure in what part of the hardware. After several attempts to provision the failing machine using different modes, I gave up thinking that it must be failing memory and ordered a new Rock64. But then I stumbled upon this post – Rock64 v2 network issues and started thinking that this looks very familiar. The author said that it’s enough to move one pull up resistor to fix the problematic board. Like shown in the picture (increased scale):

Indeed, Rock64 V3 release notice is saying:

Improved transmission packet loss on gigabit Ethernet by adjusting
LED0/CFG_EXT and LED2/CFG_LDO1 pull up resistor connect to 3.3V instead
of 1.8V.

I decided to give it a try since I could not use that board anyway. I managed to remove the pull-up resistor from its original place. Just to give you the proper scale, here it is:

But when I tied to solder it to the new position I got stuck. My instruments and skills were not allowing me to do that, it’s just too small – 1 x 0.5 mm! I was desperate and decided to check the documentation the last time and found something interesting. The release note about V3 is wrong, it’s not a pull-up it’s a pull-down resistor now!

If you look a the Rock64s’ (V2) schematics you can find the following part, the red arrow shows the move of the pull-up resistor (DNP – Do Not Populate):

And if you look at Roc64’s (V3) schematics you can see that, indeed, the resistor was moved and became a pull-down one (NC – Not Connected) since LED2/CFG_LDO1 is connected to the ground wire now thought R3331.

Why this difference is important and how it can help me? The answer is simple, you can find the ground wire everywhere on the board and use a proper, not an SMD resistor, to pull down. That’s exactly what I did. I couldn’t find a 4.7 K Ω resistor so I used 2 K Ω one and soldered its one lead to the ground contact of the audio socket and another lead to the pad closer to the RTL8211F chip (Ethernet Transceiver). I put some isolation on the resistor’s leads, just in case. The soldering was much easier compared to my miserable attempt to solder the original one (SMD 0402), although I would recommend you to read some articles on how to solder miniature components upfront.

Booted the board up, and provisioned Kubenetes using my Ansible role!

How about CFG_EXT? The release note is wrong in this case too, it was kept in its original position. Which makes perfect sense according to RTL8211F documentation.