Search the Community

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!

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).

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 use the POE hat from pine64 (https://pine64.com/product/rock64-quartz64-model-b-poe-add-on-board/) It fits as long as your heat sink is not too large.

I have a Rock64, purchased in 2019, that has been running happily for 4 years. I was recently experimenting with hooking it up to a relay board and now I am unable to connect to the internet. I am unsure whether something is fried on the board itself or if this is a software problem I can fix, and unsure how to figure that out. Details I have learned more about relay boards now, so I'll do a few things differently and more carefully next attempt, but I had the 5v pin powering the relay board and the 3v pin, GPIO3_A4, and GPIO3_A5 connected to the control side to control two of the board's relays. When connected the Rock's power leds were still on, but either the OS or the internet was down, not sure which. When I then disconnected the relay board, everything worked as normal for a few iterations, but then it remained down even with the relay board disconnected. At this point I logged in over a serial console and found the OS working just fine, but no sign of the ethernet port. This is the current state and I'd like to figure out if it's a fixable one! I have ordered a wifi dongle, but I'd also like to get back ethernet if possible. I believe the only thing I've done intentionally that may have changed the state of the filesystem was that I ran `dpkg-reconfigure network-manager`. Not sure if that changed anything. The orange light on the ethernet port is lit constantly when the board is on. The green light is always off (now). `lspci` produces no output. `ip a` lists only the `lo` interface: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever `/etc/network/interfaces`: #source /etc/network/interfaces.d/* # Network is managed by Network manager auto eth0 iface eth0 inet dhcp # address 192.168.70.70 # netmask 255.255.255.0 # gateway 192.168.1.1 # dns-nameservers 8.8.8.8 8.8.4.4 USB, emmc, and sd still work Boot output The only thing I note here is the line `Net: No ethernet found.` and, at the bottom, several `EXT4-fs error`s. The first makes sense, that's what I'm seeing after bootup. Not sure what to do about the second, if anything.

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

On Jammy (Gnome, current, Rock64), I had to manually install dkms before the script would work.

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

Thanks! I can confirm that the script works on my Rock64 board, running bullseye CLI with the current branch. At first I thought it wasn't working, but then I moved it to a different spot and tried an open WiFi network. I'm still not sure if I can get it working with my normal WPA2/WPA3 network. Oh, and you might want to change "edge" to "$BRANCH" in the manual instructions, too.

Hm, I retried with defreeze and freeze and now instead of armbian-firmware-full, the armbian-firmware got hold. For security I will also set again the armbian-firmware-full on hold... Better safe than sorry. Apologies, above happened on my rock64. Strange though: the rock64 image holds armbian-firmware, the rockpro64 holds armbian-firmware-full? Or is that because I added the headers as well on the rockpro64 and not on the rock64...? Hm, tried to update packages and the firmware using armbian-config, and it updates the full. Is it possible that the omv (installed using armbian-config...) uses a different update strategy and uses the armbian-firmware NOT full? Will set a hold on both to be sure...

Hi all. I have a Rock64 board with 1GB RAM. I downloaded this image https://dl.armbian.com/rock64/Ubuntu_xenial_default_nightly.7z and I wrote it on the SD card (Samsung EVO 16GB) using both Etcher and dd command. But when I power the board, all 3 leds light up and remains on, nothing else happens. I have the same behaviour with the 0.6.0 stretch-minimal image downloaded here https://github.com/ayufan-rock64/linux-build/releases The only images that works are the 0.5.10 downloaded here https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.10 What's wrong? I can exclude problems with power supply (I bought the one they suggested on their site, 5V 3A) and with SD card because I have no problem with 0.5.10 image. I tested both xenial-mate and stretch-minimal (with the XFCE4 desktop environment installed later) images without problems. Thanks in advance. Matteo

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

Hello, I've followed the steps on the Rock64 Armbian download page to enable overclock on my Rock64 running Armbian Xenial 5.60 (rock64 4.4.124-rk3328), yet I can't seem to increase the CPU clock frequency. I've also checked the Documentation-> Fine Tuning page where the same steps are listed. Steps: sed -i "s/MAX_SPEED=.*/MAX_SPEED=1510000/" /etc/default/cpufrequtils systemctl restart cpufrequtils I've checked the CPU frequency now and it looks like it's stuck at the default value. Shouldn't the new CPU frequency now be listed as 1.51GHz by the below commands ? rock64:~$ cpufreq-info -c 0 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 68.0 us. hardware limits: 408 MHz - 1.30 GHz available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.30 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, interactive, performance current policy: frequency should be within 600 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz. cpufreq stats: 408 MHz:0.00%, 600 MHz:94.66%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.30 GHz:5.34% (285924) pi@rock64:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 408000 600000 816000 1008000 1200000 1296000 pi@rock64:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 600000 pi@rock64:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1296000 pi@rock64:~$ I've found this post on the forum related to overclocking the Rock64, alas it does not specify the steps to increase the CPU frequency. *** I am aware of the issues that CPU overclocking might bring, yet I am willing to test stability and share the results and I already have a heat sink and 5V fan in place. *** I am using the official Rock64 PSU (5V DC at 3A).

Hi! I am using the as of this date latest armbian image Armbian 22.11 Jammy, Kernel 5.15.y, Size: 495Mb, CLI, Release date: Nov 30, 2022 for my board: https://www.armbian.com/rock64/ I am not sure if this is specifically an issue with the CLI image, or if both images are affected. I am not using a GUI. I configured a static IP address via netplan (generated and applied the config) and installed a dhcp server. The dhcp server sometimes kept failing to start on reboot. Checking the logs showed that even though the isc-dhcp-server depends on the network being configured before it tries to start, that actually systemd sometimes starts isc-dhcp-server before it configures the network interfaces. I believe this is a bug in the OS! The only thing that helped was to completely remove/mask the default NetworkManager and switching to systemd-networkd and systemd-resolved instead. I don't have time to report this in multiple bugtrackers, I am just documenting this issue here in the forum, and hopefully it will help somebody that has the same issue or who wants to fix this. Also crossposted the issue to the isc dhcp-user mailinglist: https://lists.isc.org/pipermail/dhcp-users/2023-February/022826.html But I don't think it's a problem with their service. I think it's an issue with either systemd or NetworkManager or netplan with the default NetworkManager renderer. If you want to reproduce the issue my netplan config looked like this: cat /etc/netplan/armbian.yaml network: version: 2 renderer: NetworkManager ethernets: eth0: dhcp4: no addresses: [192.168.129.22/24] routes: - to: default via: 192.168.129.1 nameservers: addresses: [1.1.1.1,8.8.8.8] And after ripping out NetworkManger as I workaround I now I changed the renderer to networkd. I think it would be better if the OS would also work as expected with the NetworkManager that it ships with enabled by default. Or make networkd the new default. Cheers!

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?

First off this is not a Rockpro64 it is a Rock64 Ver. 2 which the tags field would not let me enter. A couple years ago when I first started playing with the Rock64, I briefly used armbian as the OS. The flickering video was annoying so later I tried Manjaro which worked fairly well. Recently the (Manjaro/Arch) updates (as well as latest images) completely break the HDMI output. Since the system was rendered usless, I downloaded the latest Armbian Jammy hoping for better results. The image loaded from SD fine, I did updates manually fine, and it rebooted fine. The only problem I experience is that that anoying HDMI video flicker. It's worse when there is any system activity, IE: if the mouse is rolled over an Icon, or if that icon is clicked, the screen becomes a blur of random horizontal lines as the screen jumps. I've looked but havn't found a comprehensive solution to this issue; much of what is out there is "old news" can anyone steer me in the right direction to fix this?

Thanks for that cOrnelius. I've never messed with uboot yet I'll do some research first. As far as Manjaro goes it was fine in the previous version on the Rock 64 as well as a Radxa Rock 3A. (Manjaro-ARM-kde-plasma-rock64 (or 3A)-21.10.img) When the systems were updated to 22.06 the HDMI died. on both. I've installed Armbian 22.11.1 jammy_current 5.15.80 on the Rock 64 and Armbian 22.11.2 jammy_edge 5.15.80 on the Rock 3a. Only the Rock 64 has video issues.

This happens on both the Rock64 and Renegade and I would think other boards using the RK3328 SoC.. The fix is to patch, compile and in this case, re-flash u-boot. The attachment patch has been tested on U-Boot v2022.07/10 HDMI output appears to be broken on 6.1.y "in my experience". So if Manjaro has moved to that kernel, that would explain why HDMI is no longer working. 003-rk3328-set-VOP-QoS-to-high-priority.patch

Hello, can someone help me with my problem. I have a ROCK64 with 4GB of RAM and an ARMBIAN 5.75 stable Ubuntu 18.04.2 LTS 4.4.174-rockchip64, installed. My issue come with usb ports, from the three USB of the this device only works two: one 2.0 and 3.0. And when i have a disk connected towards usb 3.0 i have issues with port usb 2.0, it doesn't work well and I end up disconnecting the USB 3.0 to can work with my device connected towards USB 2.0 so I assume that the current power on the USB port is having issues or it's not working well. Anybody an idea? thanks!

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.

Below patch is a squash of following 4 commits borrowed from ayufan's https://github.com/ayufan-rock64/linux-mainline-kernel repo: From cc22206776d61948f6984a4f03d8013eb4f92984 Mon Sep 17 00:00:00 2001 From: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Date: Wed, 3 Dec 2014 13:23:28 +0200 Subject: [PATCH] OF: DT-Overlay configfs interface This is a port of Pantelis Antoniou's v3 port that makes use of the new upstreamed configfs support for binary attributes. Original commit message: Add a runtime interface to using configfs for generic device tree overlay usage. With it its possible to use device tree overlays without having to use a per-platform overlay manager. Must be: From cc22206776d61948f6984a4f03d8013eb4f92984 Mon Sep 17 00:00:00 2001 From: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Date: Wed, 3 Dec 2014 13:23:28 +0200 Subject: [PATCH] OF: DT-Overlay configfs interface Below patch is a squash of following 4 commits borrowed from ayufan's https://github.com/ayufan-rock64/linux-mainline-kernel repo: This is a port of Pantelis Antoniou's v3 port that makes use of the new upstreamed configfs support for binary attributes. ......... Change-Id: I421887697d2ba6e52aba9100100b7664760e2001 --- diff --git a/Documentation/devicetree/configfs-overlays.txt b/Documentation/devicetree/configfs-overlays.txt new file mode 100644 index 0000000000000..5fa43e0643072 ..... -- 2.35.3 You don't have to edit the fix file in the editor. Instead, apply a bad patch using the patch command to the source code. Then add the modified files to track the git git add -A. And make a commit git gui. In the commit message, add all the text that you consider important. Then extract the commit using the git format-patch -1 command From 7cfb967c52d374ddcb0fc9194f38d1d5f9d8cdd8 Mon Sep 17 00:00:00 2001 From: popcornmix <popcornmix@gmail.com> Date: Sun, 3 Dec 2017 21:43:03 +0000 Subject: [PATCH] configfs: New of_overlay API From 8637321fabb045fe8617360ef1b058978b0d8457 Mon Sep 17 00:00:00 2001 From: Phil Elwell <phil@raspberrypi.org> Date: Mon, 4 Dec 2017 14:07:40 +0000 Subject: [PATCH] SQUASH: config_fs: of_overlay_apply takes a pointer Signed-off-by: Phil Elwell <phil@raspberrypi.org> From 274dfabb947ca32116a429c582c74aaee6ff1b5b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kamil=20Trzci=C5=84ski?= <ayufan@ayufan.eu> Date: Mon, 14 May 2018 11:28:09 +0200 Subject: [PATCH] ayufan: fix overlayfs to compile on 4.17 kernel ????????????????????????????????????????????????? only: Signed-off-by: Slawomir Stepien <sst@poczta.fm> Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by: popcornmix <popcornmix@gmail.com> Signed-off-by: Kamil Trzciski <ayufan@ayufan.eu>

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?