Search the Community

Hi, First of all I am posting in Rockpro64 section because I am not seeing one for Rock64 What I need is like the title says: use OTG USB port as regular USB 2.0 port (so I can connect another device). Currently I need the 2 USB 2.0 ports (USB 3.0 is already being used with a external disk). Is this possible? OS version: Armbian 24.2.1 Jammy - Linux 6.6.16-current-rockchip64 Thanks in advance.

Hi all, I try to use a SATA/SSD connected via USB instead of a SD Card or eMMC, but it doesnt boot at all. I tried to use U-Boot for Rock64 on SPI: Release 2017.09-rockchip-ayufan-1065-g95f6152134 · ayufan-rock64/linux-u-boot · GitHub (flashed to SD Card and successfully booted on Rock64), but without success. I flashed the same Image to SD Card, eMMC and SSD. Booting from SD Card and eMMC works without problems, SSD is visible from Rock64, correct UUID is written in "armbianEnv.txt" on SSD. But nevertheless - it doesn´t boot. I use the Rock64 for my Home Automation and want to use the SSD because it should be more stable long term as a eMMC or SD Card. Kind Regards Martin

I am about ready to shoot my want to be server. I have an Ubuntu samba server running a public share on my LAN. The share has no username or password required to make it windows friendly. No other system has issues accessing it. I have a new ROCK64 running Armbian 23.11.1 Bookworm CLI. It will not mount a CIFS share at boot, but will mount it with a mount -a command. Fstab entries that have not worked: //192.168.15.150/15tb_NAS/Data/ /mnt/NAS cifs rw,user=,password=,file_mode=0777,dir_mode=0777,async,x-systemd.automount 0 0 //192.168.15.150/15tb_NAS/Data/ /mnt/NAS cifs vers=3.0,rw,user=,password=,file_mode=0777,dir_mode=0777,async,x-systemd.automount,_netdev,x-systemd.after=network-online.target 0 0 //192.168.15.150/15tb_NAS/Data/ /mnt/NAS cifs rw,user=,password=,file_mode=0777,dir_mode=0777,async,x-systemd.automount,_netdev 0 0 Relivant journalctl -xb output: Feb 08 14:58:37 rock64 mount[1355]: mount error(101): Network is unreachable Feb 08 14:58:37 rock64 mount[1355]: Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) Feb 08 14:58:37 rock64 kernel: CIFS: Attempting to mount \\192.168.15.150\15tb_NAS Feb 08 14:58:37 rock64 kernel: CIFS: VFS: Error connecting to socket. Aborting operation. Feb 08 14:58:37 rock64 kernel: CIFS: VFS: cifs_mount failed w/return code = -101 This looks like the network is not coming up in time, but I have tried x-systemd.automount and _netdev and x-systemd.after=network-online.target as options to make the system wait for the network. Shouldn't one of those fix the issue? Maybe I have been looking at this to long, and can't see the forest for the trees. Can anyone else see an issue here? I figure it's user error, but maybe there is a bug in this build? Feel free to ask questions if something is missing, and I will provide whatever I can.

After shelving my Rock 64 I dusted it off and downloaded the latest desktop image with Ubuntu Focal. The latest OS has video artifacts that the older OS did not. I can only describe the issue as "scan lines," but they are random black bars that appear through out the entire screen (as if WiFi is interrupting the signal only there's no WiFi on the device). I would like to know the best way to bisect the issue as I'm fully capable of cloning the repo, building the image, loading the image and testing it out but if there are pointers to simplify the process I'd love to hear. Hoping to give back since this is a community supported board. Thanks.

Hello community, I have just been successful building my own image of Ubuntu focal + preempt_rt (kernel 5.15.76-rt53) for my Rock64 board for the first time (a bit of additional background at the end of my post). Exciting! I had a few hiccups along the way, and I need to figure out a few more things. So far I'm happy and impressed with the project. However, given I want to share my work (and the resulting image(s)) I would like to ask for some pointers on what is the best way to go in regards of forking armbian/build and the changes I found myself doing. I have added my kernel compilation flags to config/kernel/linux-rockchip64-current.config but I feel like maybe I should create a new file, something like 'linux-rockchip64-current-rt.config' but I do not know if the compile.sh will find it (or how to make it find it) if I do so. What would be the best way to go about it? I added the PREEMPT_RT patches to patch/kernel/rockchip64-current , but again, there should probably be a folder for RT maybe? (I wonder how to make compile.sh find it). I created userpatches/lib.config with the content 'KERNELBRANCH='tag:v5.15.76'' to use the latest PREEMPT_RT compatible kernel, ideally this could be scripted to use the latest closest to 'current', which also would avoid needing to modify the patch/kernel/BOARD_NAME folder. I also needed to remove the box64 package cause it would stop building my image (GPG key outdated?) is this package necessary for a minimal installation? I don't think I found I needed it so far. I left a comment about it in this github issue: https://github.com/armbian/build/issues/3968#issuecomment-1310390875 I needed to add a couple of additional cmdline flags, I edited by hand (after booting the board) the resulting /boot/armbianEnv.txt with 'extraargs=nohz_full=3 isolcpus=3' and that worked, but I'd like to create the image with that already done. What would be the best place to do that? userpatches/customize-image.sh ? If I place anything in userpatches/customize-image.sh am I able to run the build just from there? Thank you very much for any pointers you can give me about best practices to go about it, anything I did wrong, or templates to follow. My first goal is to provide a reproducible build of ubuntu focal + preempt_rt for the rock64 board (which I'm very close!), but I'd be happy to extend the work to be able to apply the PREEMPT_RT patches to any board saving people a bit of the guess work I needed to do (at least for as long the patches are not part of the kernel by default!). Additional background: I need to use Ubuntu as my plan is to use ROS 2 on it, and the officially supported distro is Ubuntu (and focal happens to be the most useful for my use-case). I am aiming, in conjunction with some members of the ROS real-time working group, to ease the entry barrier of learning to make real-time apps for robotics. I am using a Rock64 board because it's similar to a Raspberry Pi 4, as I am unable to source a Raspi4 and I believe it is the same for everyone. Bonus: a quick test (running 10min) of cyclictest with stress on the system provided the following plot on latency (74us max, 15us min, about 20ish us average):

The initial installation went fine from the flashed image on SD card, and still works fine. However, after using armbian-config to attempt to transfer the OS and bootloader to the eMMC card, nothing actually changes. It says it formats the card and then goes through the process of transferring the files, or at least it looks like it does. But when I reboot it it's still running on the SD card and no files appear to have been transferred to the eMMC. fstab lists the UUID of the SD card and not the eMMC at all; this is also true of the bootenv section of armbian-config. One thing I did notice is that there are some new directories under /mnt : '/mnt/nand-sata-install.Jkf7AG' and '/mnt/nand-sata-install.xo9PVr'. Both of these contain 'bootfs' and 'rootfs' directories, but these are all empty. Also, 'lsblk' shows some sort of boot partitions on the eMMC: mmcblk1 179:32 0 29.1G 0 disk └─mmcblk1p1 179:33 0 28.8G 0 part mmcblk1boot0 179:64 0 4M 1 disk mmcblk1boot1 179:96 0 4M 1 disk Previously, I used this board with ayufan, booting directly from the eMMC card. Before flashing the SD card I erased the boot files from the eMMC card, and as I said the initial installation seemed to go just fine

Description USB3 has been enabled in mainline since 2021 View the full article

I installed tvheadend on Armbian 22.08 Jammy and Bullseye using the 5.15 kernel. Tvheadend runs fine for a while and then freezes and disconnects filling the log file with the following message: rock64 kernel : au0828: recv_control_msg() Failed receiving control message, error -71. At first I thought it was a problem with Jammy, but I still had the same problem on Bullseye. So I switched to the legacy kernel 4.4.213-rockchip64 and I do not have the problem. I am using a Rock64 Ver. 2 with usb dvb tuner for tvheadend and it is stable running Bullseye with kernel 4.4.213. I am not sure what changed between these kernel versions, but it seems to cause this problem.

Hello, i am pretty new to arm embedded. I have a Rock64 V3.0 2019-0626 So I downloaded Armbian 22.08 Jammy XFCE from https://www.armbian.com/rock64/ and copied it on a 265GB SanDisk Extreme microsd XC 1 V30 A2 using Balena Etcher. Boot process did work, but startxfc4 did not work. The system just went on a blackscreen, but i could still switch to another terminal with alt+f1 ... Best regards, Bo

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

Hello everyone, i was thinking about running a jellyfin server on the Rock64, is there any chance for hardware encoding? Thank you in advance Regards

A month or two back, when I installed Armbian, I had to revert to an older kernel, 5.10.63-rockchip64, which has known vulnerabilities. I needed to be able to boot off of a USB 3 HDD, so I had to revert it and hold updates for the kernel/kernel headers. These are the commands I used to revert to the older kernel: sudo apt install linux-dtb-current-rockchip64=21.08.2 linux-image-current-rockchip64=21.08.2 sudo apt-mark hold linux-dtb-current-rockchip64 linux-image-current-rockchip64 Fast forward to today, where the issue with USB 3 has been apparently resolved in the latest kernel, I tried to unhold the kernel/kernel header updates, that seemed to work. But after running an update, nothing. It's still showing 5.10.63-rockchip64 when it should be 5.15.63rockchip64. I tried to run firmware updates and everything, still not updating the kernel. It still also says Armbian 22.05.3 Jammy. In Armbian Config, the latest kernel I can choose from seems to be one with borked USB3 support, linux-image-current-rockchip64=22.05.3 5.15.48-rockchip64. If I select this kernel, my OS will be bricked since I would not be able to boot off of the USB HDD. linux-image-current-rockchip64=22.08.1 5.15.63-rockchip64 should technically exist as it is the current Armbian release for this board, but it is nowhere to be found in Armbian Config and even after doing an unhold, the system will not update to the latest borked kernel either.

(Note: this is crossposted from an ATS issue, since I think it might be quicker to get answers here. Will post on one thread when I get answers that work in the other) Have installed ats on my Rock64, running Armbian 22.05 Jammy with kernel version 5.10.63, and am having trouble getting the fan to spin. The fan I'm using is the one that comes with this case, and it spins when I connect it to a battery. One possible issue is that I had to manually add an entry for PWM_CTL: running sudo find /sys -name pwm\*, I get: /sys/kernel/tracing/events/pwm /sys/kernel/tracing/events/pwm/pwm_apply /sys/kernel/tracing/events/pwm/pwm_get /sys/kernel/debug/tracing/events/pwm /sys/kernel/debug/tracing/events/pwm/pwm_apply /sys/kernel/debug/tracing/events/pwm/pwm_get /sys/kernel/debug/pwm /sys/class/pwm /sys/bus/platform/drivers/pwm-clock /sys/bus/platform/drivers/pwm-regulator /sys/firmware/devicetree/base/pinctrl/pwm1 /sys/firmware/devicetree/base/pinctrl/pwm1/pwm1-pin /sys/firmware/devicetree/base/pinctrl/pwmir /sys/firmware/devicetree/base/pinctrl/pwmir/pwmir-pin /sys/firmware/devicetree/base/pinctrl/pwm2 /sys/firmware/devicetree/base/pinctrl/pwm2/pwm2-pin /sys/firmware/devicetree/base/pinctrl/pwm0 /sys/firmware/devicetree/base/pinctrl/pwm0/pwm0-pin /sys/firmware/devicetree/base/__symbols__/pwm0_pin /sys/firmware/devicetree/base/__symbols__/pwm3 /sys/firmware/devicetree/base/__symbols__/pwm1 /sys/firmware/devicetree/base/__symbols__/pwm1_pin /sys/firmware/devicetree/base/__symbols__/pwmir_pin /sys/firmware/devicetree/base/__symbols__/pwm2_pin /sys/firmware/devicetree/base/__symbols__/pwm2 /sys/firmware/devicetree/base/__symbols__/pwm0 /sys/firmware/devicetree/base/pwm@ff1b0030 /sys/firmware/devicetree/base/pwm@ff1b0020 /sys/firmware/devicetree/base/pwm@ff1b0010 /sys/firmware/devicetree/base/pwm@ff1b0000 My guess was that I should use /sys/firmware/devicetree/base/pinctrl/pwm1. Putting that in my ats config, when I run ats -t, I get: info:'SYSTEM' Table info: 'BOARD' Table info: 'NAME' = ROCK64 info: 'CPU' = RK3328 info: 'THERMAL0_CTL' = /sys/class/thermal/thermal_zone0/temp info: 'THERMAL1_CTL' = ERROR info: 'PWM_CTL' = /sys/firmware/devicetree/base/pinctrl/pwm1 info: 'MAX_CONTINUOUS_THERMAL_TEMP' = 45 info: 'MIN_CONTINUOUS_THERMAL_TEMP' = 20 info: 'MAX_PWM' = 255 info: 'MIN_PWM' = 40 info: 'ALWAYS_ON' = false info: 'PROFILE_NAME' = profile0 info: 'PROFILE' = 0 info:'Pratio' timers info: 'Pratio[ -20 - 20 [' = 0 info: 'Pratio[ 20 ]' = 40 ... info: 'Pratio[ 45 ]' = 255 info: 'Pratio[ 45 - 70 [' = 255 (the temperature range is low so that the fan would definitely run if it was working) When I run this command, the fan doesn't spin. For what it's worth, here's the rest of the output of ats -t: Stopping for[ seconds ]............... 3 CPU Temperature[ max 70 °C ].......... 0 GPU Temperature[ max 70 °C ].......... 0 Fan PWM Duty Cycle value[ 0 - 255 ]... 190 -------------------- Running for[ seconds ]................ 10 CPU Temperature[ max 70 °C ].......... 39 GPU Temperature[ max 70 °C ].......... 0 Fan PWM Duty Cycle value[ 0 - 255 ]... 0 -------------------- Any idea what might be wrong?

Running latest Jammy image and trying to attach USB to SATA 3 SSD. I tried two different USB 3 to SATA adapters and they both show up in lsusb: Bus 005 Device 002: ID 2109:0711 VIA Labs, Inc. VL711 SATA 6Gb/s bridge sudo fdisk -l doesn't show drive, but I can plug into my desktop and it mounts disk. Could be related to https://github.com/MichaIng/DietPi/issues/5378

Today I flashed the latest version CLI Jammy img instead of my old OS.First system boot,I can get the IP from my router DHCP and I can ping the Board's IP,but SSH connection refused.Now the Latest System won't start SSH service in first boot?I haven't a monitor,so I cant check the system booted or not.

Since Linux 5.15, the USB3 port on ROCK64 does not work anymore with Armbian. The following kernel errors are shown: usb 5-1: USB disconnect, device number 2 [...] usb usb5-port1: Cannot enable. Maybe the USB cable is bad? This has been reported by multiple users with multiple drives and cables, also disabling UAS does not help. lsusb shows the drive/device, but lsblk does not. I know the ROCK64 is not currently supported by Armbian/has no maintainer, so I'm not expecting anything, just posting this as information and probably someone with more insights into the rockchip64 kernel build has an idea or workaround.

Hello, A while back i was using my rock64 as a media player running armbian with some success. Since a hiatus and reinstall of the latest armbian focal mainline release, the i2s output no longer works. I can get output on the 3.5mm jack, but not on the RCAs of the DAC board. I spent some time playing around the fdtget/fdtput with no success as i don't really know what i'm doing in that space. Does anyone know how to enable I2S? Volumio got mentioned allot in my google searches, so i tried that and viola the DAC works again. volumio@volumio:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: HDMI [HDMI], device 0: ff000000.i2s-i2s-hifi i2s-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: I2S [I2S], device 0: ff010000.i2s-rk3328-hifi rk3328-hifi-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: I2S [I2S], device 1: ff010000.i2s-snd-soc-dummy-dai snd-soc-dummy-dai-1 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: SPDIF [SPDIF], device 0: ff030000.spdif-dit-hifi dit-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 volumio@volumio:~$ uname -a Linux volumio 4.4.154 #1 SMP Tue Oct 13 11:37:38 CEST 2020 aarch64 GNU/Linux on armbian i get **** List of PLAYBACK Hardware Devices **** card 0: rockchiprk3328 [rockchip,rk3328], device 0: ff000000.i2s-i2s-hifi i2s-hifi-0 [ff000000.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: rockchiprk3328 [rockchip,rk3328], device 1: ff010000.i2s-rk3328-hifi ff410000.codec-1 [ff010000.i2s-rk3328-hifi ff410000.codec-1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: rockchiprk3328 [rockchip,rk3328], device 2: ff030000.spdif-dit-hifi dit-hifi-2 [ff030000.spdif-dit-hifi dit-hifi-2] Subdevices: 1/1 Subdevice #0: subdevice #0 Regards, Dan

Description Restore Rock64 and RockPi 4A/4B/4C builds. How Has This Been Tested? It hasn't yet. Need to get these changes integrated to the build system so I can test the images on the SBCs :) Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

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

Updated Armbian on Rock64 today, then lightdm stopped working. After peeling the layers it appears to come down to Xorg giving signal 11 "Segmentation fault" /usr/sbin/lightdm --debug [+0.12s] DEBUG: XServer 0: Launching X Server [+0.12s] DEBUG: Launching process 2575: /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch [+0.12s] DEBUG: XServer 0: Waiting for ready signal from X server :0 [+0.12s] DEBUG: Acquired bus name org.freedesktop.DisplayManager [+0.13s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0 [+0.15s] DEBUG: Process 2575 terminated with signal 11 root@rock:~# whoami root cd /usr/lib/xorg file Xorg Xorg: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=f42da704ae0d3ae4698db2960364a313b08e111f, for GNU/Linux 3.7.0, stripped root@rock:/usr/lib/xorg# Xorg Segmentation fault root@rock:/usr/lib/xorg$ sudo Xorg --configure Segmentation fault uname -a 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux apt-cache show xserver-xorg | grep Version Version: 1:7.7+22 Version: 1:7.7+19ubuntu14 Is there a way to fix this without downgrading?

hello I have installed rock64 armbian debian bullseye, on the emmc card and I have an ssd disk by usb3, the disk is mounted in /etc/fstab, but every day approx it gives me an error blk_update_request: critical target error, dev sda, sector 250069504 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 [18241.624593] Buffer I/O error on dev sda, logical block 31258688, async page read I have tried several discs and it happens to all of them Is there something to be able to install so that I don't get that error

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.

Hi, I have a Pine Rock64 v2.0 SBC and with the image Buster xfce desktop (I guess this is the right one that mentions here), the board has random freezes and impossible to use. So far the board does work good with Ayufan Debian buster image. Anyone had and idea why? I post here since I need to implement hwaccel so I can use this board as RTSP server using a UVC USB camera (Arducam). Thanks.

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?

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.