08-11-2020, 12:13 AM
(This post was last modified: 11-02-2020, 12:25 AM by wilsonYan.)
hello,
for anyone interested I managed to generate an openwrt image for the rock64 based off the latest master tree
Link to download:
https://yadi.sk/d/TfX6-MYy3RTf5h?w=1
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?
Code: 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 https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/kmod/5.4.74-1-63fa2731cb0f8e88239410e4cc044b42/kmod-usb-net-sr9700_5.4.74-1_aarch64_generic.ipk
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.
Thanks,
~Chainu
02-01-2021, 09:23 PM
(This post was last modified: 02-01-2021, 09:41 PM by chainu127.)
wilsonYan,
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 dtoc.py script running. In the end I reverted openWrt's u-boot package to 2020.07 just to get something working
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.
Thanks!
~Chainu
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:
Code: diff --git a/package/kernel/linux/modules/fs.mk b/package/kernel/linux/modules/fs.mk
index d43542b17e..327e236e8d 100644
--- a/package/kernel/linux/modules/fs.mk
+++ b/package/kernel/linux/modules/fs.mk
@@ -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)
endef
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.
~Chainu
04-05-2021, 10:17 PM
(This post was last modified: 04-05-2021, 10:37 PM by wilsonYan.)
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%)
https://disk.yandex.com/d/TfX6-MYy3RTf5h?w=1
04-23-2021, 01:37 AM
(This post was last modified: 04-23-2021, 02:35 AM by wilsonYan.)
updated again, this one has an updated r8152 driver from net-next tree, realtek nic firmware also updated from kernel.org
so you should be able to plug in a 2.5G realtek based adapter and be good to go but it still seems to be unreliable for me with this build
Hi @ wilsonYan , I'm using a snapshot built of 20.x something and after loading the intel driver my intel i350-t4 based NIC seems to work good.
Have you tried using the Rockpro64 using kernel 5.10 - if so, any noticeable differences compared to kernel 5.4?
And do you see any benefits for me using your latest OpenWrt build?
05-14-2021, 11:16 PM
(This post was last modified: 05-14-2021, 11:33 PM by helpmerock.)
Hi Wilson,
How to install this? There are three files - which file to use in Etcher?
rootfs - file - no boot partition <- a message in Eatcher
The other two files - rock64 does not boot.
|