Search the Community

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.

Moved to correct forum and added rock64 tag.

Hi all, I have a Rock64, running ioBroker, and want to update the npm/nodejs to update all the adapters - mainly MQTT with which I have some problems. Trying to run apt update or iob nodejs-update, I run into: The repository 'http://apt.armbian.com stretch Release' does no longer have a Release file. in several versions. Can you help me? Sources.list is (changed, this works now) deb-src [trusted=yes] http://archive.debian.org/debian stretch main non-free contrib deb [trusted=yes] http://archive.debian.org/debian-security stretch/updates main non-free contrib Armbian.list is: deb https://apt.armbian.com stretch main stretch-utils stretch-desktop With hopful regards Martin

Hi all, I installed the newest bookworm image (Armbian_community_24.5.0-trunk.250_Rock64_bookworm_current_6.6.22_minimal.img.xz😞 flashed it to SD card, booted... Rock64 boot was okay, via PuTTY it asked me to log in, but I have no PW, not any credentials, of course. Shouldn´t it ask me for a root PW first??? BR Martin

Hi Werner, What do you mean with outdated? Armbian Stretch? Armbian in general surely not... I run my home automation system on Rock64 and need to update npm to 8.xx anf nodejs to 18.xx I succeeded to update npm, but not yet nodejs, is it because Armbian? How can I change if needed to be future proof? Kind Regards Martin

Hi @Gunjan Gupta For rk3328 SoC do you suggest any build having : 1. GPU support 2. Weston support 3. VPU support Any build version with any kernel for board having rk3328 SoC (rock-pi-e, rock64,etc.).

Hello , looking to upgrade from SBC Rock64 to RockPro64< however, on the homepage it is mentioned, that https://wiki.pine64.org/wiki/ROCKPro64_Software_Releases Since my Rock64 is running aready Linux kernel 4.4 and i am looking to upgrade, both from Rock64 and from SDcard to eMMC, my question, if this limitation still applies to RockPro64 with newer editions of Armbian, also since there is no mention of it on the official Armbian Page for RockPro64 https://www.armbian.com/rockpro64/ Thank you very much

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

I have compiled with Armbian build (btw i reported that RockPro64 and Rock64 download pages give 502 Bad gateway) 1. Armbian_23.08.0-trunk_Rockpro64_jammy_current_6.1.46_minimal.img 2. Armbian_23.08.0-trunk_Rockpro64_jammy_current_6.1.46_cinnamon_desktop.img With SPI disabled, the img boots fine, but when reboot/restart takes place, board gives black screen, no U-boot activity, no white light. It will boot again after restart if reset pressed or power off/on Shouldnt board reboot normally? PS nd after u-boot log/text this screen shows prior booting