Search the Community

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.

Running Armbian on a Rock64 (RK3328) board and in turn running pihole for DNS. I cannot seem to be able to get rid of the secondary IP address that is pulling from DHCP. the main static address I set duing pihole setup is 10.4.5.2. Any way to remove the 10.4.5.98? ifconfig from terminal only shows the .98 address.

Was anybody successfull installing Armbian to Rockbox (Rock64 chipset)?

I've been dealing with this problem for a while now, and after seeing this thread, I decided to dive in a little deeper. With LZ4-compressed lists, running an apt search on my Rock64 currently takes at least 20 minutes. As other users have reported, it appears to be bottlenecked by CPU, and is not saturating the storage I/O. Needless to say, this is not a usable speed. Based on what I've found, I believe with substantial confidence that there is no performance problem with LZ4. This should not be too much of a surprise, because speed, especially decompression speed, is LZ4's primary objective; it is in fact considerably faster than LZO in that regard, which means that it's dramatically faster than DEFLATE (gzip). I cannot imagine any conceivable case where switching from LZ4 to DEFLATE would result in decompression performance improvements, and indeed it does not seem to do so here. In any case, you can trivially see this for yourself by using the command-line lz4 utility to decompress one of the compressed list files in /var/lib/apt/lists. On my Rock64, decompressing the largest of these (/var/lib/apt/lists/apt.armbian.com_dists_buster_main_binary-arm64_Packages.lz4, which weighs about 1.8 MB) takes around a tenth of a second. For some perspective, my test run of an apt search took just over 2700 seconds, so if it did spend all or most of this time doing LZ4 decompression, then it could easly have decompressed every list in the directory over a thousand times each. I am not an expert on the intricacies of file compressors, but I find it to be highly unlikely that LZ4 is responsible for the slowness we're seeing here. I had a look at the strace output for the search operation. I'm new to reading straces, but I think I can confirm what a previous poster said, which is that it's accessing the same files over and over again with small reads, often many times in the same place. It is unclear to me what function this serves, but this appears to be what takes up the majority of the runtime. If you would like to see for yourself, I've made the full strace output available at https://fluora.net/strace_apt-search_armbian.7z. Be warned that it's around 260 megabytes when uncompressed, but since it's extremely repetitive, it compresses efficiently, and the 7z archive is only about 96 kB. In addition, you may compare this to the strace of a sane apt-search operation that I took on an x86 laptop running Debian Bullseye with gzip-compressed package lists, available at https://fluora.net/strace_apt-search_debian86.txt (116 kB, not compressed). This isn't much more than a guess, but I wonder if apt is decompressing the entire list with each one of these repeated read operations - this would explain not only the slowness, but also why switching to uncompressed lists seems to help (since it allows the storage cache to render the repeated accesses cheap). From what I've found here, I strongly suspect that something is wrong with the version of apt distributed by Armbian. I don't know enough about the code to know where to start looking, but this is the point where I would hope that someone familiar with Armbian's modifications to apt could help out.

Indeed. For example, my Rock64 and my Neo3 are stable at 1.3 GHz with -25mV and -50mV respectively vs. default OPP values. Silicon lottery. It's still strange that H6 DTS lacks a proper OPP. Maybe with Unstable kernel, based upon 5.11 mainline? Some patches for H6 were included in 5.11 and accompaining DTS.

Maybe my problem is a bit different then. My Rock64 (with both Armbian Stable and Unstable) does not reboot after "sudo poweroff": it performs the shutdown sequence, but does not really "power off". It is halted, does not respond to login or ping, but the peripherals are still powered and the board still draws the typical idle current (about 220 mA); the heatsink stays warm too.

My Rock64 using Armbian_21.02.3_Rock64_buster_current_5.10.21.img.xz works fine. It didn't used to. I had the same shutdown, autorestart problem. Last year, my problem first occurred with the Armbian_20.08.1_Rock64_buster_current_5.8.6.img.xz version when I upgraded to the 5.9.14 kernel. I used the armbian-config program to back out the kernel to the 5.9.11 version and the poweroff then worked. One thing that I noticed when I restored the kernel is that my hardware ethernet address xx:xx:xx:xx:xx:xx changed. I had OMV5 installed and had to run omv-firstaid to fix the ethernet definition. My Rock64 with Armbian has worked ever since. I don't know why the address changed or why it is now working. So, I now decided to install the current Armbian_21.02.3_Rock64_buster_current_5.10.21.img.xz on a new SD card. Everything works just fine. Using 'sudo poweroff', it shuts down immediately without restarting. I also installed OMV5 and the shutdown from OMV works also. Could that restoring of the kernel and some process changing the hardware ethernet address have fixed it ?

@firewire10000 Hi, I can confirm this behaviour, both with the Stable image (kernel 5.10.21) and with the latest Unstable from yesterday (kernel 5.11.15). Unfortunately I don't know how to fix it. I tried rebuliding the kernel from the latest "Edge", with CPU Power Management enabled, but nothing changed. The Rock64 is not supported by Armbian, so if powerdown is important to you, I would advice sticking with Ayufan images.

Hi I've just downloaded Armbian_21.02.3_Rock64_buster_current_5.10.21.img.xz for my Rock64 and flashed the image to a microSD card using BalenaEtcher. Over the last couple of days I've been writing a menu based script that creates a shutdown script to spin down HDDs during the shutdown phase on Linux based SoC PC. The reason behind the script is to get around an apparent problem whereby HDDs are forcefully being shut off when SoC PCs power off. I have posted this problem myself on the Open Media Vault forums, I have come across it here on the Armbian forums, the ODROID forums and also the Stack Exchange forums. During my script development and testing I have been using ayufan's Rock64 images found [here](https://github.com/ayufan-rock64/linux-build) as they've always worked for me compared to the Armbian ones which sometimes never booted up or froze halfway through booting. Unfortunately OMV 5 decided to play up overnight and the web-GUI stopped working all together. After several different fixes I decided it was best to wipe the OS and start again. Whilst I had the opportunity, I thought I could try Armbian again. The good news is it actually boots now and I'm able to install OMV 5. Sadly I don't seem to be able to shutdown my Rock64 at all unless I unplug the power barrel connector which of course damages the files and is causing the HDD's to re-spin up. I first noticed the Rock64 not shutting down when I tried to shutdown from OMV's web-GUI. To rule OMV being the problem I tried some of the shutdown commands from the CLI: reboot -p shutdown -P poweroff -p As shown in the video below you can see it goes to shutdown but soon after it starts back up. https://youtu.be/h-fi7iHLMBI With ayufan's Rock64 image with the same shutdown command it shuts down with literally 5 seconds and then remains off. Does anyone know what's going on here?

Hi all, I'd love to run my sas2008 card on armbian. Im currentky testing the ayufan 0.10.12 build and it is working with my sas cards flawlessly even with sas expanders and 16x hdd attached. https://github.com/ayufan-rock64/linux-build/releases On armbian or any other release for that matter there is insufficient boot wait time for to card, i believe these cards take around 400ms to boot with bios rom deleted. The patch provides 1 second wait time. Working kernel patch is here thats been pulled into the above release https://github.com/nuumio/rp64-linux-mainline-kernel/releases any chance of having this incorporated? My skillset with kernel/image building is very short in supply so im not sure how much i can do but point me in the right direction and ill try, it appears this is a very usefull feature for those with lsi sas cards for bigger nas boxes. Krita

@Henry Delphing I'm trying to set up an "OrangePi kernel building" environment on one of my SBCs, a Rock64 2GB running Armbian stable. It's a difficult task, because documentation is often obsolete, sparse and conflicting; plus, every pre-cooked build environment is quite rigid about what to build and from which source. Anyway, my goal is to replicate Hexdump's kernel: clone jernej's sources, apply hexdump's patches, load hexdump's kernel config and build. Then sort out which of the various DTSs actually enables USB on the PiZero2. If and when I'll reach my goal, I'll post a link to the working kernel here, I promise.

Search the forums. Don't expect official documents: as we have stated several times, Rock64 is not supported by Armbian, and therefore we won't put resources into it. If you, or any other community member, wants to work on documenting the problems or fixing them, feel free to do it. I don't even own the board. And please start a different thread on the "Peer-to-Peer Support" subforum. Any further post about the Rock64 problems will be deleted from this thread.

I have the same problem with my Rock64. I couldn't get it to boot. Are there docs about the problems, anywhere?

Wow rollin the dice. Im optimistic on their behalf and won't make any passive comments about the Rock64

Hello. I'm using the latest image from https://www.armbian.com/rock64/ installed today. As description say, it is possible to overclock the board to 1.5ghz, but it didn't work. root@rock64:~# cat /sys/devices/system/cpu/cpu{0,1,2,3}/cpufreq/scaling_available_frequencies 408000 600000 816000 1008000 1200000 1296000 408000 600000 816000 1008000 1200000 1296000 408000 600000 816000 1008000 1200000 1296000 408000 600000 816000 1008000 1200000 1296000

Hi, in my case the test is on a Rock64 (4GB, v2 edition) using latest current Buster or Focal. The problem is in the first init configuration assistant. When selecting the "User language based on your location", after selecting es_AR.UTF-8 (I am from Argentina) it "auto-detects" my keyboard layout as AR which belongs to Arabic iirc (which is wrong). After this of course I can't type anything right on terminal. I had to fix it over ssh by issuing the command: sudo dpkg-reconfigure keyboard-configuration.

Ok, I missed that one. Anyways, installing Buster of Focal with legacy Kernel makes my Rock64 (4GB) to kernel fault randomly and crash, even at start: )

Hi, I wanted to try this build so I cant test HW (using the legacy kernel). But, is impossible to make Rock64 boot correctly, having random kernel crashes, It does boot with the 5.10.x kernel version and work just fine, but I need the Legacy one so I can test HW. I can only attach a photo since there is nothing I can do since the OS is halt. Any ideas? Thanks.

I have Rock64 board with latest Armbian Focal flashed on it. I want to use it with this HDMI display by Waveshare: https://www.waveshare.com/wiki/7inch_HDMI_LCD_(H)_(with_case) Now, when I connect it to Rock64 it runs as 1080p downscaled by HDMI controller on display, resulted image is garbage, even though it is present. As was discussed here: https://forum.armbian.com/topic/10071-tinker-board-hdmi-resolutions-do-not-all-work/ current kernel/u-boot doesn't have required video mode to run this display properly. I tried to set required mode with xrandr but with no success. Can anyone help me to figure out how to patch kernel/u-boot to get this thing work properly? And what exactly is setting video mode kernel or u-boot? I've found where video modes are set in u-boot source, but I suspect that adding required video mode there won't be enough, am I right?

And shit I still have problems, so I'm looking for the right .dtb for my mx10 for this buster image of the station M1, I'm a bit lost to tell the truth, but I found an old post If anyone still has .dtb files for the mx10 I'm very interested ... Otherwise I tested several dtb with different results Boot OK but no eth with rk3328-roc-pc.dtb and rk3328-rock64.dtb (I noticed that rk3328-rock6.dtb is the only version that uses the led of my box in the correct blue way in operation and red in standby) Boot OK and eth OK but problems with the usb using the 3 versions rk3328-evb.dtb No boot with rk3328-box-liantong.dtb, nor with the dtb taken in the latest version of libreelec (rk3328-box.dtb) What a misery to find this damn .dtb ... Thank again..

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?

It seems to be system-specific. Pine H64 B + Hirsute: doesn't build. Pine H64 B + Bullseye: doesn't build. Pine H64 B + Focal: builds, doesn't install OPiPC + Hirsute: builds. OPiPC+ + Bullseye: builds. (All sunxi-dev) EDIT: Rock64 + Bullseye: doesn't build. (dev as well)

And thank you for the info concerning the new models to come RK3566 and RK3568 it seems to be really promising but it will surely also be much more expensive, novelty oblige .. So far I have only seen 2 SOCs with this rk3566 / 68 (geniatech and rock64) are there other manufacturers?

Rock64's image with 4.x kernel and desktop is as the same as it.log: http://ix.io/2PXh

Rock64's image with 5.x kernel didn't have filesystem error, log: http://ix.io/2PX6