Search the Community

Hi, I'd like to control ws2812 led's via gpio spi. I'm using this octoprint build by ldiaz: I checked /boot/armbianEnv.txt and there's overlay_prefix=rock64 and after enabling spi via armbian-config also overlays=spi-spidev. Then I rebooted but ls /dev/spi* shows nothing. Can anyone help?

The GPIO pins on the Rock64 are very similar to the Raspberry Pi's GPIO, except the Raspberry pi calls pin #19 GPIO 10, pin #21 GPIO 9 and pin #23 GPIO 11. Where as the Rock64's pin #19 is GPIO3_A1, pin #21 GPIO_A2 and pin #23 GPIO3_A0. The Rock64 documentation does say that it is quasi-Raspberry Pi compatible, but it's hard to find anyone who has actually tested this. Here is the GPIO layout of the Rock64, compared to the Pi 3 I'm currently trying to figure out if a display such as THIS can be connected to the Rock64's GPIO pins without any major issues. User documentation for the display can be found HERE on page 2, in the PDF named 5inch_HDMI_Display_User_Manual. Any information will be greatly appreciated.

How is the 1-wire bus enabled on a Rock64 with Armbian 20.08.17 Bionic? I have enabled the w1-gpio through armbian-config. The /sys/bus/w1/devices/ folder is empty after sudo modprobe w1-gpio and sudo modprobe w1-therm. Below is what is in the armbianEnv.txt file in the /boot directory. verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=cbeeff94-c38d-4a79-b10a-3854a2470be4 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u overlays=i2c7 spi-spidev w1-gpio In the /boot/dtb/rockchip/overlay/ directory there is a file rockchip-w1-gpio.dtbo. I have connected the VCC pin of the DS18B20 to 3v3 physical pin 1, ground of the DS18B20 to physical pin 9, data of the DS18B20 to physical 7. The DS18B20 address and w1_bus_master1 do not appear in the /sys/bus/w1/devices/ folder. What more is required to see the DS18B20 and take readings? I have already connected an 18x2 LCD to i2c and am writing information to the LCD using python. Thank you for the help. Perry

I'm trying to get a Rock64 board working with a wifi USB dongle, sold as RTL8188 and which is in fact a 8188eu. I use the latest armbian-buster as downloaded a few days ago. The dongle appears in dmesg when plugged in, but no module is loaded. I can manually load the 8188eu module and get no errors, but no wifi interface appears. Ifconfig, iwconfig and nmtui don't see anything they could use for wlan. I have installed the firmware-realtek package as well, it made no difference. I can get the module 8188eu autoloaded at boot, but that doesn't change the non-availability of a wlan interface. Any help appreciated. I have posted the armbianmonitor -u output in the required field. ( here it is again: http://ix.io/2Dee )

Hi, I have a simple question: we need to buy some ARM 64 boards and we would like to select the Rock64 (2G and 4G) - I saw that now Rock64 is CSC (community only supported). Being our priority to use Armbian OS on the boards, does this means that we could not see Armbian no more supported (no upgrades) in the next future? Thanks Franco

I'm a complete noob to compiling kernels and have been struggling (and failing) for the past week to get an RT kernel compiled using Armbian build and reading various threads in the forum. Is it even possible? If so, what config options need to be set to get the correct kernel version matching the available rt patches? Thanks!

Since this is a different issue I split this topic into a separate one to take care of or check at least somewhen. ------------------------------------------ Oh well. There IS something wrong but not with the toolchain download... rock64 focal current desktop HOSTLD tools/mkimage tools/Makefile:134: recipe for target 'tools/_libfdt.so' failed Makefile:1278: recipe for target 'tools' failed [ error ] ERROR in function compile_uboot [ compilation.sh:220 ] [ error ] U-boot compilation failed [ o.k. ] Process terminated #compilation log: tools/libfdt_wrap.c:149:11: fatal error: Python.h: No such file or directory # include <Python.h> ^~~~~~~~~~ compilation terminated. error: command 'x86_64-linux-gnu-gcc' failed with exit status 1 make[1]: *** [tools/_libfdt.so] Error 1 make: *** [tools] Error 2 Seems to depend on Python2 19 | int ____ilog2_NaN(void); | ^~~ File "./tools/dtoc/dtoc", line 50 print result ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(result)? File "./tools/dtoc/dtoc", line 50 print result ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(result)? make[1]: *** [include/generated/dt-structs-gen.h] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [tpl/dts/dt-platdata.c] Error 1 make: *** [tpl/u-boot-tpl.bin] Error 2 make: *** Waiting for unfinished jobs.... Yup. Forcing Python2 works. Not sure if Python2 was still default on Bionic but I guess so. Might become an issue with building on Focal in future. Need to test this somewhen...

First time user here. I got a Rock64 board and flashed Armbian_20.08.1_Rock64_focal_current_5.8.6_desktop.img using Etcher to an SD card. When I try to boot, nothing happens. If I examine the SD card on my Linux PC, there is only one partition on it and it appears to be a kernel image. I assumed that the .img file would have the U-Boot partition as well. Is there a different type of image file I should be using that would contain everything that I need to boot? If not, how do I create such an image?

I have two Rock64 single-board computers running Focal Fossa. One is stable and the other gets segmentation faults when compiling and sometimes a kernel oops. After some searching, my understanding is this can be fixed by slowing down the memory speed by installing rk3328_ddr_333MHz_v1.13.bin from the ayufan-rock64 GitHub repository into uboot along with possibly rk3328_miniloader_v2.46.bin as well. Unfortunately, I'm clueless how to do this. I'm running the latest Armbian Focal Fossa Server from August 19 with the 5.7.17 kernel. Do I need to build a new image or can I patch an existing SD card? I'm sorry if I there is already a thread on this. I searched and could not find enough information that would allow me to proceed on my own.

Hi, I need some guide and steps required (and if possible) to enable hardware acceleration using FFmpeg. Is the only thing I need since the idea is to use this SBC as Surveillance platform (for example, with Motion+Motioneye or Shinobi). Currencly without hardware accel, using 3 rtsp cams uses each 100% of a core (which translate to 300%). I've searching a lot, but I saw hwaccel with others apps, but not in particular with ffmpeg. I already managed to compile it with --enable-rkmpp (h264_rkmpp hevc_rkmpp vp8_rkmpp vp9_rkmpp) and available hwaccels: vdpau cuda vaapi drm opencl. Any help will be much appreciated. Currently fresh installed OS: Armbian Focal Thanks in advance.

Hello Armbian community My HiFiBerry DAC HAT works well on my Raspberry Pi 3B with RasPiOS. However, I would like to put it on my Rock64 to use the higher Ethernet and USB speed it offers. As far as I can tell, HiFiBerry DAC is in the mainline Linux kernel - it is mentioned in the source code, but I do not understand programming, so I cannot see if it is used. Is the HiFiBerry DAC supported in Armbian's kernel? If so, how can I activate and use it? I put the HAT on the Rock64 and installed Armbian_20.05.2_Rock64_buster_current_5.4.43.img.xz , and it booted without problems, but I could not get sound out of the HiFiBerry DAC, and Alsamixer showed no controls for the sound hardware. I also tried making a Virtualbox to compile the Armbian kernel, and I could get the build environment to work, but I did not find any clues to include support for the HiFiBerry DAC - yes, I am truly clueless when it comes to programming, but I can follow a step by step recipe. Please give me a recipe for getting the HiFiBerry DAC to work on Rock64 with Armbian. Best regards Freddy

Hi! I've 2 rock64 boards -- 4gb and 2gb bought with 1 year difference The problem -- both boards have same MAC address. Changing it with macchanger has no effect, same for cloned mac in nmtui. Also I tried this in armbianEnv.txt: root@rock64:~# cat /boot/armbianEnv.txt verbosity=1 overlay_prefix=rockchip rootdev=UUID=48ad169b-7620-4c84-89fa-6c9a0fcde766 rootfstype=ext4 ethaddr=a7:71:b0:90:17:1f usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u But mac stays the same. I've plugged usb ethernet just to avoid conflict on same network, but how can I change the MAC of eth0 ?

Hi, Around the forums, I've seen that some people have been successful in running the lima driver on Amlogic or Allwinner hardware: https://forum.armbian.com/topic/14180-bananapro-lima-driver-problems/ https://forum.armbian.com/topic/11424-playing-with-limamesa-mali-drivers/ However, I couldn't seem to find any posts with Rockchip hardware, specifically the ROCK64. I tried to enable it myself by doing the following, but was unsuccessful so far. enable kernel module lima via "sudo modprobe lima" update /etc/X11/xorg.conf.d/01-armbian-defaults.conf as below per the lima wiki instructions (also tried w/o the "Device" section) Section "Monitor" Identifier "Monitor0" Option "DPMS" "false" EndSection Section "ServerFlags" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection Section "ServerFlags" Option "AutoAddGPU" "off" Option "Debug" "dmabuf_capable" EndSection Section "Device" Identifier "Lima" Driver "modesetting" Option "AccelMethod" "glamor" EndSection Section "OutputClass" Identifier "Lima" MatchDriver "rockchip" Driver "modesetting" Option "PrimaryGPU" "true" EndSection Install kodi from the standard repo install updated graphics drivers from Oibaf's PPA start kodi, Armbian desktop (XFCE), or weston (can't confirm if weston was running lima actually) However, no matter what I do, I always get output via llvmpipe as opposed to lima, as also seen in my Xorg.0.log. A couple things I also noticed: other boards also have an armsoc video driver like xserver-xorg-video-armsoc-sun4i, but there isn't one for Rockchip. However, I'm also not sure if this is for the proprietary blobs as opposed to lima. there is a rockchipdrm module loaded in my kernel. I tried to blacklist it and load lima in /etc/modules-load.d, but it seems that it didn't work (rockchipdrm still loaded, lima not) when I booted. I guess it's baked into the kernel? So, can anyone point me in the right direction of where to go from here? My goal is to run kodi via lima so that I can use mainline kernels + mesa with minimum/no patches (vpu might still be tricky).

Just wondering if anyone has Webmin running on their Arm system. I have encountered problems installing and using a dependency "apt-show-versions" I have studied and attempted to resolve the issue using information on this page https://serverfault.com/questions/845192/dependency-problems-while-installing-webmin It goes into a fair bit of detail, but unfortunately nothing is working. Can anyone put me on the right track?

After the next (last) update, the system does not boot, there is no ssh access, and the monitor does not turn on. I just didn't install updates for three weeks and decided to update yesterday What should I do, re-install the system ? The loader is located on the sd card, and the system is on the hdd, using the 4.4.x kernel

L.S. After installing Armbian_20.02.1_Rock64_buster_current_5.4.20.7z on my 4GB rock64 running on SD card - I could run for days 2 processes with "openssl speed" resulting in 2 CPU's 100% busy. - But when I added a third "openssl speed" it only takes minutes to freeze the board. - Further the "ondemand" scaling_governor is active (default setting) I noticed that distributed /etc/default/cpufrequtils contains line: ==> MAX_SPEED=1390000 This value is not in the list with valid values for this CPU : ==> 408000 600000 816000 1008000 1200000 1296000 1512000 After updating this to valid value and restart service cpufrequtils: ==> sed -i "s/MAX_SPEED=.*/MAX_SPEED=1296000/" /etc/default/cpufrequtils service cpufrequtils restart The rock64 is now already a few hours running happily 100% CPU on all 4 its core's at appr 80C. It even runs happy now with 4 CPU's 100% with MAX_SPEED=1512000 for nearly an hour, throttling down to 1.3 or 1.2GHz at appr 84C - Can this be reproduced by some one else using the default distribution with 4x100% CPU usage? - Can it be that I have an old level rock64 board (I bought it appr 2 years back) that is causing this issue? - Is it possible that the CPU / kernel freezes because of an incorrect MAX_SPEED value? ref: Linux rock64 5.4.27-rockchip64 #20.02.6 SMP PREEMPT Tue Mar 24 23:43:02 CET 2020 aarch64 GNU/Linux regards Eric Experimenting with armbian in these worrying times.

Hi all. I wrote a small guide on enabling pps-gpio by modifying the device tree. With a PPS signal it's possible to setup your board as a Stratum 1 time server for your local network or the NTP pool. I used this method on a Rock64 but it should be applicable on most board. PPS-GPIO on Rock64 with Armbian legacy (4.4.X) kernel Cheers.

EDIT: Just realized I posted this in the bug tracker forum. My apologies! See:

Anyone have an issue where on a fresh install with apt update and upgrade I create a hotspot then have openvpn connect on boot. It works fine as a hotspot with 200mbps up and down but when the traffic is routes through a vpn by connecting openvpn the board will crash/become unresponsive if the upload is used heavily. Works great until I run a speedtest and on the upload the board will crash. Normal use is fine even pegging download causes no issue. Le potato s905x works amazing in this regard and never crashes period. Is this a known bug?

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?

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.

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

I am running last stable armbian with kernel 4.4.192-rockchip64 on emmc - really everything works nice (only thunderbird is very slow) - thx a lot for your work. The only thing I could not figure out, how I can wake up from suspend by keyboard or mouse. The armbian image uses org.freedesktop.login1.suspend to suspend - normally I am used to upower or pm-utils and there it was until now all the time possible to wake up with keyboard. Its quite uncomfortable to wake up the Rock64 with the power button - hidden, very small hole, I just use now a wooden chopstick for wakeup. Does anybody know, how to configure wakeup-hooks / wakeup-events for systemd / logind.

I have the Rock64 4G Version with emmc module Since the latest Kernel Update two weeks ago on friday the board does not boot up anymore. (I was on Stretch initially and updated regularly since.) Even with a newly flashed sd card and without emmc module the board will not but into armbian. I managed to boot into raspbian buster 5.91 once, but after rebooting it, it failed again and stayed that way. until now I have tried the latest 3 images. The Kernel is now 4.4182 and is unchanged whatever I do. with any armbian on an sd card i am getting: Failed to start armbian zram config - failed to start journal service Failed to flush Journal to Persitent Storage rockchip64 #6 and at some point the boot sequence stops with something like: work_pending+0x10/0x14 or I am getting consistent timeouts from "waiting for device" with the original emmc card it gives me: ... BUG: spinlock bad magic on CPU#2 goes to: secondary_start_kernel +0x190/0xbc 0x2cxa188 repeats and stops there also since the beginning I sometimes get: "fixing recursive fault. Reboot is needed!" - without reboot improving anything of course.. I am afraid that at this point of failure notices and kernel panics I have no idea how to proceed anymore.

I cannot connect by VNC/ FTP from more than one computer on network to my Rock64 but can do multiple SSH. Once I have one computer connected by VNC I want to go elsewhere on my network and monitor same session or ftp in. but once one session is running others are not allowed. also only allows ftp from computer with other session. if reboot can connect but loose original session. how can I allow multiple sessions.