Search the Community

That's great so what can I do to help with the latest rock64 kernel 5.4? Should I get a setup with rock64 plugged into a monitor and then compare the boot info from Armbian_19.11.3_Rock64_buster_current_5.3.11 (working) vs Armbian_19.11.6_Rock64_buster_current_5.4.y (broken) If this is a good starting point then happy to assist...

Hello, bumping this thread, as this is also about the rock64 and usb3 with a more recent image. It seems to me that now for the "legacy" kernel (tested here with Armbian_19.11.6_Rock64_buster_legacy_4.4.207 image) there is support for the usb3 bus, but for the mainline Armbian_19.11.5_Rock64_buster_current_5.4.6 there is not (the 19.11.6 current kernel image gives me an oops on boot and no network). Is there something I can do to add it to the mainline/current image? Tia, Huey output on mainline: root@rock64:~# uname -a Linux rock64 5.4.6-rockchip64 #19.11.5 SMP PREEMPT Fri Dec 27 21:46:18 CET 2019 aarch64 GNU/Linux root@rock64:~# lsusb -t /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M output on legacy: root@rock64:~# uname -a Linux rock64 4.4.207-rockchip64 #1 SMP Sun Jan 5 00:23:38 CET 2020 aarch64 GNU/Linux root@rock64:~# lsusb -t /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M

a little update regarding my rk3318 box - at my last try it was hanging at u-boot -> see: i finally got it booting by dd'ing the u-boot from this image: xenial-minimal-rock64-0.5.15-136-arm64.img.xz from https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.15 to my sd-card and afterwards dd'ing the trust.img from: on top of it ... not really straight forward, but works at least best wishes - hexdump

Hi guys, I recently bought a Rock PI 4 and installed Armbian Buster with kernel 5.4.6. The os is booting fine but I am facing major performance issues when trying to download from the internet. I have also a Raspberry Pi 4 connected to the same switch (via LAN) and when I execute the following command curl -L http://speedtest.belwue.net/1G > /dev/null I am getting download speed of approx 8MB/s on my Raspberry but only 2MB/s on my Rock PI 4. From connection side and rooting there is no difference. While using the same Armbian version on my Rock64 I am getting the same speed as my Raspberry Pi. Is this a known problem with the Rock PI 4 or am I missing something important? I also tried other kernel versions but the problem persists. One thing to mention: I tried the same command with a local webserver (same network, same switch) and there I was able to get download speeds of about 60MB/s, so it seems to not being an issue with the LAN port itself. Any ideas? Thanks! Bye

I believe the problem with the dts definition which I found a year ago was fixed by Ayufan for his mainline builds, but still exists in the official repo. My rock64 is not available for me to test right now. Perhaps someone else could take a look? https://forum.armbian.com/topic/9413-make-419-kernel-available-again-for-rock64/?do=findComment&comment=70578

Can also confirm issues on my new Rock64. USB3 works on fresh install of Buster server 4.4 Linux rock64 4.4.198-rockchip64 #27 SMP Fri Dec 27 21:32:05 CET 2019 aarch64 GNU/Linux No USB3 device recognized on Buster server 5.4 Linux RockHole 5.4.6-rockchip64 #19.11.5 SMP PREEMPT Fri Dec 27 21:46:18 CET 2019 aarch64 GNU/Linux USB2 works OK on both. EDIT: Also no USB3 on Linux RockHole 5.3.11-rockchip64 #19.11.3 SMP PREEMPT Mon Nov 18 21:03:09 CET 2019 aarch64 GNU/Linux

Same problem here with a clean installation of the current image for rock64 (19.11.5 - 5.4.6). With the legazy image (4.4) there is no such problem with usb3.

there's a tool to test this: https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test @tkaiser wrote one too back then.. but I can't remember where I have it anymore.. Nevermind https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test#L3 https://github.com/armbian/build/issues/546

What is the supported way, if any, to redirect /var/log.hdd to a directory located on a real HDD drive? One of my systems has an eMMC to boot and operate from, and a HDD hooked up on the USB3 port. "Ideally" I'd like to use only the HDD, but the poor/incomplete USB3 boot support on the Rock64 V2 (with Bionic at least) had me to buy an eMMC and live quietly with it. As it is, I'd like to move out of the eMMC all the data that is either written often, or that it could get bigger with time passing. For the logs, however, I don't think to have found a clean way to support the relocation of /var/log.hdd on a different drive/partition, unless I hack the armbian-ramlog script (something I *don't* want to do). Or I could disable completely the log2ram feature. Thanks!

Add me to the list of users who have lost the USB3 port once I've switched to kernel 5.3.11. On one of my boards I have had to hook a monitor to understand why the Rock64 did not boot anymore from the eMMC. The problem is it is failing to mount the USB3 connected HDD and then it goes in recovery mode. The Ethernet port is also not configured. Booting from a SD card with Armbian Bionic 5.90 in it I first upgraded to the latest 5.98, which brought in kernel 4.4.198 (I was on 4.4.192), then using armbian-config I switched to the new kernel 5.3.11. On powering on the board (the switch poweroff the board instead of power cycling it), not depending on a fstab pointing to a missing drive the system booted normally, with the Ethernet port properly configured. The USB3 port is still missing from lsusb -t output

Ok...so the verdict is I have a bad TTL adapter. I have a Rock64 and some jumper wires, and the Rock64 has a UART on it capable of running a 1500000 baud...so I wired up the debug pins on the OPi to the UART on the Rock64 -- and bam, I get stuff that I can at least read. (The only bad thing is that the Rock64 leaks voltage out of the UART pins...so the board tries to power on as soon as you hook it up.) Without the SD card? I think you're right -- it tries to boot into Android. I see a bunch of messages from the kernel, and then it drops into a shell. (Interestingly, it also spits out a bunch of errors b/c the filesystem is read-only...but whatever.) With the SD card? Here's what I get: �DDR Version 1.14 20180803 In Channel 0: LPDDR4,50MHz CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size= LPDDR4,50MHz CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CSMR4=0x1 MR5=0x1 MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 Bus Width=32 Col=10 Bank=8 Row=15/1S=2 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x7MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x7R19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR 0 training pass! channel 1 training pass! change freq to 400MHz 0,1 channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel change freq to 800MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = Boot1: 2018-08-06, version: 1.15 CPUId = 0x0 ChipType = 0x10, SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOfmmc0:cmd5,20 SdmmcInit=0 0 BootCapSize=0 UserCapSize=15193MB FwPartOffset=2000 , 0 StorageInit ok = 182421 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 GPT 0x3190d20 signature is wrong LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xa69c4 RunBL31 0x10000 NOTICE: BL31: v1.3(debug):f947c7e NOTICE: BL31: Built : 20:19 BTW -- I didn't have to connect TP50625 to anything to get it to boot off the SD card. So...next step -- maybe try to build a new U-Boot?

Also, if you are going to use the board for LUKS encrypted storage, you may want to have good disk IO performance. So you should probably aim for something with USB3 or PCI support. Rock64 seems like a good option to me, if you want something affordable.

I have a 4G Rev 2 Rock64 that is running like a champ on current - 5.4.2 as of this writing, as far as USB and Ethernet are concerned. I did have to blacklist UAS for all my USB drives, and now the board is rock solid even with heavy disk and network IO. I do have one problem though, I have no sound. I have the following loaded (automatically): root@chdock:/home/sugata# cat /proc/modules |grep snd snd_soc_rk3328 16384 0 - Live 0xffff800008dc9000 And yet, I get this: root@chdock:/home/sugata# aplay -l aplay: device_list:272: no soundcards found... I searched around this forum and nothing obvious came up. Any ideas?

Hi guys, I have recently bought a Rock64 to improve the performance of my VPN gateway. First tests look very promising as you can see here: root@rock64:~# openssl speed -evp aes-128-cbc -elapsed You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 15394610 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 64 size blocks: 12591175 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 6719021 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 2448108 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 352617 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 177668 aes-128-cbc's in 3.00s OpenSSL 1.1.1d 10 Sep 2019 built on: Sat Oct 12 19:56:43 2019 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-H2OJIf/openssl-1.1.1d=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 82379.18k 268611.73k 573356.46k 835620.86k 962879.49k 970304.17k root@rock64:~# openvpn --genkey --secret /tmp/secret root@rock64:~# time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-cbc Sat Dec 14 10:26:40 2019 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode real 0m4.978s user 0m4.945s sys 0m0.032s Unfortunately when executing a simple curl, the throughput is very low: root@rock64:~# curl -L https://speed.hetzner.de/1GB.bin > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 2 1000M 2 29.9M 0 0 2090k 0 0:08:09 0:00:14 0:07:55 3106k When using Ubuntu 18.04 Bionic I am reaching speeds of 8,4MByte/s. I have checked the openvpn process and it seems that it is only using 25% of CPU, whereas when using in Ubuntu it is using 50-60%. What are the differences here and why is Armbian limiting the process to 25%? Thanks! Bye

The strangest thing happened today. I switched of my rok64 rev.2 and connected to my PC to move the files of my USB HDD. My plan was to change the disk format from NTFS to EXT4. Then when i plugged it back in the rock64 wouldn't boot properly. Turns out my USB 3 port isn't working anymore with the USB HDD or any other USB drive. The light comes on for my SSD but fdisk -l doesn't see it. Could one of the firmware updates broken it? UPDATE... I downloaded the latest Ayufun arm64 bionic build and booted from this. My USB 3 HDD was picked up fine. I've gone back to the new Armbian Bionic build and it doesn't work. Only on USB 2 ports. Something must have changed with the latest build (u-boot / firmware) that's caused this issue. If you need some logs, please let me know... Will need a hand with the commands to run.

Many thanks for your response. I just don't understand why. With my old system stretch-openmediavault-rock64-0.9.14-1159-armhf.img everything worked without problems. Now I have determined: after about 30min to 1st hour I can quite normally use hostname on e.g. Access OMV GUI. That is very confusing.

Sorry for the long delay ... I used the Espressobin and Rock64 pro. With my espressobin I noticed the extra material in the slot was stressing the connector. I ended up going with another carrier board like this - https://www.amazon.com/gp/product/B07T7NJZTY/ref=ppx_yo_dt_b_asin_title_o07_s01?ie=UTF8&psc=1 I tried several kinds, the ones with the little flip SIM card holder held the sim card more consistently. The little snap in types kept snapping out. Some have minute sizing differences, one fit perfectly on the espressobin, some wouldn't clip in. I really dug that little sim card adapter at first, but it ends up being a real pain if you do anything but put it in and leave it.

I have a 4G Rev 2 Rock64 that is running like a champ on current - 5.4.2 as of this writing, as far as USB and Ethernet are concerned. I did have to blacklist UAS for all my USB drives, and now the board is rock solid even with heavy disk and network IO. I do have one problem though, I have no sound. I have the following loaded (automatically): root@chdock:/home/sugata# cat /proc/modules |grep snd snd_soc_rk3328 16384 0 - Live 0xffff800008dc9000 And yet, I get this: root@chdock:/home/sugata# aplay -l aplay: device_list:272: no soundcards found... I searched around this forum and nothing obvious came up. Any ideas?

Same here, after updating to the 5.3.11 kernel my Rock64 4GB rev2 doesn't come up from the SD. I have a USB SATA-SSD, but no HDMI attached. The 4.4 kernel works perfectly fine, so I reverted back to that one. I guess we'll have to wait some time for the current branch to become fully stable.

I have been testing the latest Buster Server builds - kernels 4.4 and 5.3 versions on my rock64 board In both cases I see a number of syslog entries relating to device ttyFIQ0 not starting. Does anyone else have this issue? Any ideas how to remove stop it from trying to start? thanks

After 2 boot crash restarts my Rock64 4GB rev2 on Micro SD has come up on 5.3.11 kernel. rock64:~$ uname -a Linux rock64 5.3.11-rockchip64 #19.11.3 SMP PREEMPT Mon Nov 18 21:03:09 CET 2019 aarch64 GNU/Linux It looks like the first two times `pstate: 60000085` then on the 3rd time: `pstate: 20000005`. 3rd time still has stack trace related to zstd but otherwise makes it through. I have USB SATA-SSD (Pine store), eMMC (pine store) cards and another 6 Rock64's if there is anything I can do/provide. I'm tempted to try load up Kubernetes on them all with this image and see how stable it is. Okay, it lasted about 5 minutes. Has a Pine store heatsink. Failed during apt upgrade (download fast 1Gbps) but nothing after that. Have switched to a 30A 5V supply running 5V (multimeter) just in case the Pine store PSU is too weak but haven't been able to get it to boot again. ArchlinuxARM has come up on first boot with 5.3.1 and crashed after a few minutes.

Thanks for fixing this! I couldn't do umlauts on my Rock64 via ssh. The internet suggested editing etc/inputrc, but I figured this couldn't be the root of the problem. So have been a little lost here for a while. --- food for search engine: (arg: 6)

If you follow the link I posted above, you will see at the status matrix that, indeed, encoding is not yet implemented. It has the most standard and easy to implement and use interface, v4l2-m2m XU4, MC1 and HC1 are sold now for less than $50, which I consider cheap considering its power, features and stability. Take into consideration that one of these can do the work of four to six H3 boards, for example. And if you want to build a farm, you can stack several HC1 or MC1, and put a fan on them, which will make them run steadily at maximum frequency. If you still want something cheaper with HW encoding, then you can go for a 1Gb Rock64, but these boards are having lots of stability problems lately.

Hello, this was my way to make RTC DS3231 works on rock64. apt-get install i2c-tools - /etc/rc.local /lib/udev/hwclock-set /dev/rtc1 exit 0 - /lib/udev/hwclock-set if [ -e /run/systemd/system ] ; then # exit 0 /bin/enable_dtoverlay i2c0 i2c@ff150000 okay echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device fi #if [ -e /run/udev/hwclock-set ]; then # exit 0 #fi HCTOSYS_DEVICE=rtc1 Copy to /bin/ and make executable https://raw.githubusercontent.com/ayufan-rock64/linux-package/master/root/usr/local/sbin/enable_dtoverlay systemctl stop systemd-timesyncd.service systemctl disable systemd-timesyncd.service systemctl stop fake-hwclock.service systemctl disable fake-hwclock.service sudo apt-get -y remove fake-hwclock apt install chrony

Hi all, and thanks for this great install script! I've been using a Raspberry Pi 3 as my main video player for a while and I recently switched to a Rock64. After installing the required dependencies with the media script and using mpv-gbm for playback, I noticed that the video playback was choppy and mpv would drop frames, even for "small" (i.e. non-4k) videos. I tracked down the problem to the display mode not being set right by mpv: whatever the video format, my display would be set to 3840x2160p60 (as seen from /var/log/kern.log). After manually setting the right display mode, the video playback is perfectly smooth and there are no more frame drops. For example: mpv-gbm --drm-mode=25 bbb_sunflower_1080p_30fps_normal.mp4 mpv-gbm --drm-mode=19 bbb_sunflower_1080p_60fps_normal.mp4 You can get a list of the DRM display modes with: cat /sys/class/drm/card0-HDMI-A-1/modes | nl -v 0 As a side note, I have not been able to play 2160p content at more than 15 fps and trying to play 2160p60 content even resulted in a corrupt display (green bands and pieces of picture jumping around). Thanks again!