Search the Community

I have a Rock64 running the armbian buster 10 OS, and then Running Home Assistant in a Docker. The problem i have is after a period of time the OS puts the Rock64 to sleep or uses power reduction and that drops the Home Assistant , and SSH. This is do not want t happen sice i want the OS running full time and all the time to monitor the Home Assistant and sensors. How do I stop it from going to sleep or into power reduction and have it always available?

I've got a Rock64 1GB (rk3328) running Focal with the legacy 4.4 kernel. I've compiled and installed from source various things like libmali, libdrm, mpp, ffmpeg, and gstreamer, and have successfully gotten ffmpeg and gstreamer to do hardware decoding and gstreamer doing hardware video encoding. I also managed to compile and install xserver 1.20 from the rockchip-linux Github and have it running a barebones LXDE installation. I am now setting my sights on Kodi. I have stock LibreELEC installed and working on another sdcard, but my TV only supports 50Hz, 59.96Hz, and 60Hz refresh rates, meaning that 23.976fps content does not play smoothly. I've read enough to understand that the Kodi GBM renderer that LibreELEC uses does not support the Kodi feature that allows for the playback and audio to be synced to the nearest available refresh rate, meaning that if there is any hope of getting that feature working on this board, I am going to have to compile Kodi for X11 or Wayland. I'm aware of JMMC's excellent media script, and I've relied on it heavily for what source packages need to be installed, build parameters, and other information. (Thanks JMMC!) I ran into some problems compiling Kodi for X11. Specifically, when trying to link the `kodi-x11` binary against libEGL.so and libGESLv2.so from the libmali package compiled from source, linking fails with an ocean of "undefined reference" errors to various gl functions, starting with this: build/rendering/gles/rendering_gles.a(RenderSystemGLES.cpp.o):RenderSystemGLES.cpp:function CRenderSystemGLES::SetScissors(CRectGen<float> const&): error: undefined reference to 'glScissor' Compiling succeeds when linking instead against the "stock" versions of the libraries from libegl-dev and libgles-dev, but then when trying to run `kodi-x11`, I get "./kodi-x11: symbol lookup error: ./kodi-x11: undefined symbol: glScissor." Interestingly, the same function that the linker complains about when trying to use the libmali versions of these libraries. Before I spend more time trying to make this work, I want to make sure I'm not wasting my time. Is the current state of development for this platform such that it is actually possible to run Kodi with hardware video decoding/playback within an accelerated X environment such that Kodi's "sync playback to display" function works as intended? Or am I going to have to buy a TV that supports proper cinematic refresh rates? Thanks all!

I see you are using mainline (current) kernel, try legacy. Also, have you tried different versions of docker (official docker repos vs. distro repos)? I can confirm docker runs well on the rock64 with legacy kernel and Bionic package (apt install docker.io)

Hello together, for a few months im running into this problem, where i cannot initiate a docker container, it will return following error message. docker: unknown server OS: sudo -u Username docker run -d \ --name=deconz \ --net=host \ --restart=always \ -v /etc/localtime:/etc/localtime:ro \ -v /opt/deconz:/root/.local/share/dresden-elektronik/deCONZ \ --device=/dev/ttyACM0 \ -e DECONZ_VNC_MODE=1 \ -e DECONZ_WEB_PORT=82 \ -e DECONZ_WS_PORT=8443 \ marthoc/deconz Linux rock64 5.8.13-rockchip64 #20.08.7 SMP PREEMPT Fri Oct 2 10:36:32 CEST 2020 aarch64 GNU/Linux Anbody can help? Thank you in advance. Best Regards Sven

@Meier @aldrick I do have rockpro64, i have only experinced kernel freeze with some crap sata pcie cards, and yes card from pine64 stores is one of them. I run Armbian buster with kernel 5.8.13. I use OMV5 with no problems what so ever, i did update spi bootloader from ayufan, installede armbian on ssd. Boot up from and run from SSD, + 4 disk attached (1x480GB SSD, 2x3.5" 2x2.5"), i did write 4TB on one of the disks, yesterday.. No problems.. ROCK64, i have not used that board for a long time, the usb ports acts like my girlfriend when she is mad.

There is a same problem on my rock64, I found after freezing armbian firmware and armbian-config update rock64 becomes stable .

Hi there! I am trying to set up communication between an Attiny85 and my RockPro64 over UART (running Armbian, kernel `Linux rockpro64 5.8.1-rockchip64 #20.08 SMP PREEMPT Mon Aug 17 08:17:08 CEST 2020 aarch64 aarch64 aarch64 GNU/Linux`). The issue is that I can't connect to the serial port: rock64@rockpro64:~$ sudo picocom -b 115200 /dev/ttyS4 picocom v3.1 port is : /dev/ttyS4 flowcontrol : none baudrate is : 115200 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no hangup is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, logfile is : none initstring : none exit_after is : not set exit is : no FATAL: failed to add port: Filedes is not a tty Here are some details about my setup: An Attiny85 is powered from a 3V coin cell. Here is the wiring: Battery positive - Attiny85 pin 8 Battery negative - Attiny85 pin 4 - RockPro64 ground on GPIO pin 6 Attiny85 pin 6 (PB1) - RockPro64 UART4_RX on GPIO pin 21 (connected through a 1K current-limiting resistor) UART4_TX is not connected because currently I only need unidirectional communication I used Arduino IDE with a USBtinyISP programmer to program my Attiny85 with the following test code: #include <SoftwareSerial.h> #define RX 0 #define TX 1 SoftwareSerial serial(RX, TX); void setup() { // put your setup code here, to run once: serial.begin(115200); } void loop() { // put your main code here, to run repeatedly: serial.println("ping"); } I have tried using different kernels (including dev) and switching between different combinations of overlays (UART4 and SPI1 share the same pins on RockPro64). The RockPro64 itself is booting from an eMMC module, the SPI flash contains U-Boot for USB and PXE boot support. Is there any way I can fix this issue? Are there any other easy-to-use alternatives to UART for establishing bidirectional communication? Any help is appreciated! Thanks, Anton

Thank you. After more digging, I realized that the build has xfce desktop. This is a legacy focal build for ROCK64. Is there a way to specify which desktop to use during Armbian build?

Maybe you can find this here. https://wiki.pine64.org/index.php/ROCK64#SoC_and_Memory_Specification Look what board is supported and then do your homework. All info is to be found on the internet.

Right now we are evaluating on ROCK64 board running Armbian. So, the answer is yes, on the new board we also want to be running Armbian.

I am building a legacy desktop image for Rock64 and there are a few things I am trying to customize at build time. I modified userpatches/customize-image.sh, but I am not getting expected results. Here are some things I am trying to modify: 1. I want to have the desktop come up in solid black color, no image. I made the following changes to userpatches/customize-image.sh: gsettings set org.gnome.desktop.background picture-options 'none' gsettings set org.gnome.desktop.background primary-color '#000000' But I am still seeing the Armbian image on my desktop. What else do I have to modify? 2. I need to get rid of the prompt that asks for the root user password. I added the following lines to userpatches/customize-image.sh: rm -f /root/.not_logged_in_yet echo -e "password\npassword" | (passwd root) This got rid of the root password prompt, but now the image doesn't boot into the desktop GUI. It stops at the Linux CLI prompt. What else do I need to modify in customize-image.sh to make it boot into GUI? 3. I need to create another user and I'd like to have my box automatically boot as this user. I added the following lines to userpatches/customize-image.sh (in addition to stuff I added in #2 above): echo -e "$PW\n$PW\n\n" | (adduser new_user) What else do I have to modify to make the box boot as this user? 4. I would like to get rid of Locale prompt and always choose en_US.UTF-8. How would I do that? 5. I am trying to add a systemd startup script at build time. I added the following lines to userpatches/customize-image.sh: cp /tmp/overlay/*.service /lib/systemd/system systemctl daemon-reload systemctl enable myservice.service I have myservice.service in userpatches/overlay directory. But, the service doesn't start on my target. Thank you in advance for any help I can get! Incidentally, it seems like I can only post to this forum once in a 24 hour period. How can I get past this restriction? My answers may be delayed due to this.

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!

I am running armbian on a rock64 with a usb bluetooth adapter. Adding bluetooth devices with the blueman app is very hit-or-miss for me, mostly misses. I installed the blueberry app, which I have had good luck with in the past, and device connection has been great. Every device connects on the first try. Blueberry is easy to install because it has no arch, and it also appears to be relatively light on resources. So I would like to suggest that the devs consider including it in armbian by default.

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

Trying to create my first Armbian build for rock64 using native environment on Ubuntu 18.04 host. Followed instructions here https://docs.armbian.com/Developer-Guide_Build-Preparation/ to clone and build. I am running as a root. Here are the steps I performed: git clone --depth 1 https://github.com/armbian/build cd build/ ./compile.sh I selected full OS, didn't change kernel config, selected rock64, current, focal, image with desktop. I am getting these errors: [ o.k. ] Build host OS release [ bionic ] [ o.k. ] Syncing clock [ host ] [ o.k. ] Checking for external GCC compilers [ error ] ERROR in function download_and_verify [ general.sh:1296 ] [ error ] verification failed [ o.k. ] Process terminated I tried selecting different types of builds in configuration menus, but the build always fails. I tried deleting build directory and starting over several times, but no luck. I also tried adding USE_TORRENT="no" to the command line, as was suggested in several posts I found on the topic, but that didn't work either. What am I doing wrong? How can I build my image?

Images has everything you need to boot them and most of the images are also tested. But in case of Rock64 ... there are a few quality issues hidden behind different hardware revisions. Try legacy kernel 4.4.y images or go this path:

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?

This is a followup post to to confirm that the Rock64 board that was experiencing segmentation faults with the default 786 MHz memory clock on Armbian is now stable with the uboot-initialized 333 MHz setting. On a selection of computational benchmarks performance is about 77 percent of the original setting; for compilations with gcc more than 80 percent of the original performance is retained with the added advantage that the system doesn't crash and the compiler doesn't create segmentation faults. As far as I'm concerned this problem is solved and I'll try to mark it as such. Although one out of the two Rock64 single-board computers here required this configuration change, based on posts appearing on the Pine forum, my suspicion is a much less than 50 percent--perhaps closer to 10 or 20 percent--of systems in use actually exhibit this problem. Even so, I would favor a note on the Armbian support page for the Rock64 explaining how to work around system instability by reducing the DDR RAM memory clock.

Hi, Is fan control still broken? Linux rockpro64 5.7.15-rockchip64 #20.08 SMP PREEMPT Mon Aug 17 00:26:28 CEST 2020 aarch64 aarch64 aarch64 GNU/Linux echo 255 > /sys/devices/platform/pwm-fan/hwmon/hwmon2/pwm1 echo 0 > /sys/devices/platform/pwm-fan/hwmon/hwmon2/pwm1 Commands line above work, but writing anything between (like 240, 200, etc.) does not. I can hear noise imho coming from fan coils when I write 253 to pwm1, maybe it's pwm frequency too high/too low? I checked two different 80x80mm fans, same result. Fans start to spin connected to DC ~4V, so they should work for sure. From kernel side there is pwm-fan module, but it can't take any parameters imho. Every kernel version I checked comes with it's own values (lol), for. example: https://github.com/ayufan-rock64/linux-kernel/pull/40/commits/5d9fbef9cfa01846dd0b4d66249df55c85fa344f

My understanding is that this is a common problem with the Rock64 v2 boards and simply the result of some optimistic overclocking that should never have been done in the first place. While such overclocking appears to be necessary to meet the minimum performance needed for playing back certain high-definition video, my usage for the Rock64 is not watching television but for it to function as a computer. This is essentially a new board that sat in storage for six months due to certain shelter at home rules. As returning it is not an option, I would instead like to reduce the memory frequency to a rate that runs reliably. I was having difficulty converting the instructions I read for Arch Linux to Armbian and thought I'd ask here. Before adding some more waste to the landfill, I'd like to give the 333 MHz option a thorough test. I understand your reluctance to assist. It must be irritating to continually deal with manufacturers that cut corners in unexpected ways with later revisions of their hardware. Any guidance how to get started rebuilding the uboot initialization code for Armbian with the desired memory frequency would be appreciated.

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.

I don't know if you need decoding, endcoding or both. It is maybe not updated for the latest armbian release @JMCC ? but it maybe inspires you and/or work with JMCC on an update if it is on Gitlab/hub https://forum.armbian.com/topic/9310-rk3328-media-script-rock64-renegade/

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.

Yeah, I just like the Arch way of things. I started with Ubuntu like most people, and I do run Debian on one of the machines, but on my laptop I use Arch™ As for Debian being "better" I mean in the sense of "even being doable",. I brought the U-Boot upstreaming topic here because this distro does care to bring U-Boot and the like to more boards than other distros, especially ones that are not ARM-specific. As I mentioned, I didn't even know some defconfig for Renegade had been upstreamed! It was only Rock64 before, haha

Maybe change "verbosity=1" to "verbosity=7" ... Because I've currently my Rock64 working since a week with a build done with 5.8.1 kernel, and of course still using U-Boot 2017.09.