openwrt for the rock64

for anyone interested I managed to generate an openwrt image for the rock64 based off the latest master tree

Link to download:

I basically provide this as is as a proof it's doable that said it should be good to go as a basic router using ethernet vlans, and there's wireguard that can be set up via webui to try it as a vpn etc. Power usage seems good, only 1.4w-1.5w idle with only the microsd card and ethernet plugged in and working.

Don't forget to turn on  'packet steering' in the web ui and you can probably increase performance by increasing the minimum cpu frequency in the starup section by just pasting something like  ''echo 600000 >  /sys/bus/cpu/devices/cpu0/cpufreq/scaling_min_freq"  or "echo 816000 > /sys/bus/cpu/devices/cpu0/cpufreq/scaling_min_freq"
Awesome stuff, thanks for sharing! Feel free to add your img to the ROCK64 Software Release wiki page, too!
Thanks for sharing!

I'm trying to install some kmods and opkg is complaining about infompatible architecture, though the architecture is aarch64_generic everywhere. Adding --force-depends doesn't help. kmods for a different svn build of rockchip kernel 5.4.74-1 don't work either.
Apparently it wants the specific kernel build from your image. Would you be able to build and upload the kmod packages somewhere?

root@OpenWrt:~# opkg --force-depends install kmod-usb-net-sr9700
Unknown package 'kmod-usb-net-sr9700'.
Collected errors:
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-usb-net-sr9700 found, but incompatible with the architectures configured
* opkg_install_cmd: Cannot install package kmod-usb-net-sr9700.

root@OpenWrt:~# opkg info kmod-usb-net-sr9700
Package: kmod-usb-net-sr9700
Version: 5.4.80-1
Depends: kernel (= 5.4.80-1-bef9a69b0c7edeeb82435f427c7332e6), kmod-usb-net
Status: unknown ok not-installed
Section: kernel
Architecture: aarch64_generic
Size: 5049
Filename: kmod-usb-net-sr9700_5.4.80-1_aarch64_generic.ipk
Description: Kernel module for CoreChip-sz SR9700 based USB 1.1 10/100 ethernet devices

root@OpenWrt:~# wget

root@OpenWrt:~# opkg install --nodeps --force-depends ./kmod-usb-net-sr9700_5.4.74-1_aarch64_generic.ipk
Unknown package 'kmod-usb-net-sr9700'.
Collected errors:
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-usb-net-sr9700 found, but incompatible with the architectures configured
* opkg_install_cmd: Cannot install package kmod-usb-net-sr9700.
Hi wilsonYan,

First off, thank you for your work in getting openWrt compiled for the Rock64.

Secondly, I would like to replicate your work. I would like to build a completely customized image including kmods for my specific use case. I have downloaded your openwrt-rock64-messy.patch from your link above. I have tried applying this patch to the root git directory of the latest openWrt commit, 54bfebdca00f071f0982e05e69be7a7d4176147b though it does not apply cleanly.

As a sanity check and judging by the timestamp of your last post, I have successfully applied the openwrt-rock64-messy.patch in the root git directory of openWrt commit d6cb50c7ba8447f018139401d0d3821069e5f389. From there, I had a few small issues with a full openWrt build from scratch, namely with the file rk3328-nanopi-r2s.dts that was non-existent on my system, and is surely unnecessary for the Rock64 build.

After manually removing 006-rockchip-rk3328-fix-NanoPi-R2S-GMAC-clock-name.patch, manually applying (after some googling) arm64-dts-rockchip-add-usb3-controller-node-for-RK3328-SoCs.diff patch, and  "faking" the rk3328-nanopi-r2s.dts file at the end of the build process, I was able to complete a successful rock64 build with both ext4 and squashfs img variants from the openWrt build system. This successfully booted and I could access LuCI, iperf3, and the various packages that I selected in menuconfig.

I have a specific dual-port ax88179 USB 3.0 device (search Amazon VTOP USB 3.0 to Gigabit Ethernet NIC 10/100/1000 Mbps Network Adapter with Dual RJ45 LAN Ports Compatible for Windows 10 and MacOS 10.15(Intel)) that I'm trying to get working on my build. This device normally enumerates as a USB hub and then two unique network interfaces (eth1 and eth2 on top of the built in eth0 gigabit port). On your last openwrt-rockchip-armv8-pine64_rock64-ext4-sysupgrade.img.gz build, this device enumerated on the USB2 ports, but not USB3. However, a separate single NIC rtl8153 device did seem to work correctly on the USB3 port, so it is likely related to the built-in USB hub on the device.

On my build, nothing on USB3 seemed to work, including the rtl8153, despite my modifications mentioned earlier. My guess is that this is because I am using the stock openWRT kernel, not a specific kernel for rock64, even though I think the .dtb was correct. The kernel being built on commit d6cb50c7ba8447f018139401d0d3821069e5f389 was 5.4.x whereas I think your latest image included a rockchip-specific 5.10.x kernel.

On top of debugging my USB3 issue, I have plenty of other kernel-related packages that I would like to include natively in my build such as NFS and others.

Can you give a quick overview of your openWrt build process and any modifications needed to create your images? Do you have a method of incorporating the rock64 kernel patches or sources as part of the openWrt build that will allow for the kmod packages to be built successfully? Or are you building both openWrt and the Rock64 kernel image separately (with the additional network drivers that you've mentioned above) and manually combining them in the end? There are many openWrt packages I am interested in including in my build that rely on 1 or more kmod packages and I am trying to figure out the best way to get the build working on my system so that I can customize and troubleshoot my own images further.


Thank you for your continued effort in getting openWrt working and optimized on the Rock64 board.

I will try your new pre-built images and test if I am seeing issues with my Dual-NIC USB3 adapter. Part of my previous issue with enumeration must be around power delivered by the rock64 board. Using a powered USB3 hub did at least allow devices eth1 and eth2 to register. This was slightly disappointing, as I am using the 3.0A power supply with the rock64 and nothing else connected. I am currently using the same Dual-NIC adapter on the rpi4 USB3 ports without the need for the powered hub, and the pi4 has wifi enabled, HDMI output is working, a second USB (mass storage) device is connected, etc. so I would not have expected any USB power issues on the rock64. Even with the powered hub though, I was seeing iperf3 drop to 0 throughput with that ax88179 dual adapter. I'll try your image with the latest xhci patches and report back.

I'd still like to be able to compile my own image with your openWrt git diff patch if you would be so kind to provide it - I see even the old git diff patch is gone now. On my current pi4 openWrt setup I have things like NFS, ksmbd and a bunch of other opkg software installed that pull in a ton of crypto kmods and such. I'd like to get this setup replicated on my own rock64 pre-built image as I think it is the perfect device for my needs and my 4gb pi4 is just a little overkill.

Thanks for the tip on dt-platdata.c and dt-structs-gen.h for u-boot. I struggled a bit with that when updating your earlier patch to work with the latest snapshot. I was hand-modifying those files because I couldn't get the script running. In the end I reverted openWrt's u-boot package to 2020.07 just to get something working Smile

In the meantime, I'll pull the latest openWrt git commit and continue working on my build with hopes to see your patch and all of the hard work you've done.

Thank you for posting the patch, it has greatly helped. One quick note, I had to make one further modification to get NFS to compile without error, specifically kmod-fs-nfs-common:

diff --git a/package/kernel/linux/modules/ b/package/kernel/linux/modules/
index d43542b17e..327e236e8d 100644
--- a/package/kernel/linux/modules/
+++ b/package/kernel/linux/modules/
@@ -366,7 +366,8 @@ define KernelPackage/fs-nfs-common
   FILES:= \
        $(LINUX_DIR)/fs/lockd/lockd.ko \
        $(LINUX_DIR)/net/sunrpc/sunrpc.ko \
-       $(LINUX_DIR)/fs/nfs_common/grace.ko
+       $(LINUX_DIR)/fs/nfs_common/grace.ko \
+       $(LINUX_DIR)/fs/nfs_common/nfs_ssc.ko
   AUTOLOAD:=$(call AutoLoad,30,grace sunrpc lockd)

It seems you are creating your builds with glibc, is there a particular reason or benefit there? I am building with the standard openwrt configuration using musl with no problem. I realize that by using an sd card or emmc we are quite a bit less size constrained than the routers with tiny flash that openwrt was originally built for, but we are also building an image with all of the software self-contained or external ipks with heavy reliance on being built within the openwrt development system and not relying on compatible ABIs or 3rd party software to work with the image after the fact. Just wanting to see if I am missing any obvious benefits of choosing glibc over musl in my build.

I am still running into issues with my rtl8153 adapter that I use for testing, even with a powered USB hub and after including both of your recommended ethtool commands. My final setup will use the dual ax88179 adapter though. It seems to be working better than the rtl8153, but is still requiring the powered hub. I am going to try swapping out my stock Rock64 5v 3A power supply with a 4A supply made for a different USB 3.0 hub, as well as taking voltage measurements on the GPIO pins and using an inline USB voltage and current meter on the network adapters to try and squash any power-related issues I may be having.

I'll continue to update on my progress, but I am glad to be able to build an image from scratch with your patches. I see you are including the vendor drivers for rtl8153 and ax88179 so thank you for that.

I have updated the build, this looks to be the best build i've done

The resetting of the onboard ehternet works properly now (I just copied the ethernet node from the radxa dts to the rock64 dts) and the USB 3.0 port appears to be working well with ethernet nics (at least with the rtl8153, the rtl8156 still may not be 100%)

Possibly Related Threads…
Thread Author Replies Views Last Post
  Setting a MAC on Rock64 U-Boot kiriakos 2 236 03-23-2021, 04:51 AM
Last Post: kiriakos
  Getting from zero to spidev on ROCK64? MikeInMass 0 119 03-22-2021, 10:31 AM
Last Post: MikeInMass
  NextCloudPi image for Rock64, NC version 13.0.2. nachoparker 11 10,203 03-15-2021, 02:59 PM
Last Post: kiriakos
  DietPi OS for ROCK64 MichaIng 11 2,434 03-10-2021, 11:00 AM
Last Post: MichaIng
  slarm64 (unofficial slackware) Rock64 RK3328 (aarch64) mara 110 52,580 02-28-2021, 01:52 PM
Last Post: Enig123
  Linux Images (ROCK64) pineadmin 164 138,596 02-12-2021, 10:14 AM
Last Post: useful64
  Armbian for Rock64 pineadmin 26 17,633 12-25-2020, 11:07 PM
Last Post: lanefu
  RETRO-GAMING: UPDATED RELEASE OF RECALBOX FOR THE ROCK64 Mrfixit2001 31 21,324 12-21-2020, 08:17 AM
Last Post: hermes73
  RetroPie on Rock64 Luke 40 26,547 10-31-2020, 07:12 AM
Last Post: BigSkyEntertainment
  Lakka (retrogaming) os for rock64 Wizardknight 2 1,305 09-21-2020, 07:18 PM
Last Post: Wizardknight

Forum Jump:

Users browsing this thread: 1 Guest(s)