Search the Community

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!

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

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>

New bananapi M5, no net. initial boot and config failed, font missing characters would not allow me to edit networking entries. rebooted it with the power cord, started x by hand, Menu's totally different from 2 previous installs on rock64's. Finally found a terminal, and switched fonts in geany so now the keyboard is generally working. in geany, but not in armbian-config. I have edited the /etc/hosts file to setup my static address network, fixed resolv.conf and chattr +i it so nm can't destroy it. I have edited /etc/hostname but can't get it to to "take". ip a returns that eth0 is up but no ipv4 or ipv6 address can be seen ip r return emptyhanded. I can't even ping machines in the next room by address, no route This is ipv4 country here in northern West Virginia, probably a hundred miles from the nearest net connection that groks ipv6. My router does NAT so everything here is in the 192.168.xx.yy block And it has no dhcp server running. I've 7 other machines here that thanks to the NAT in the router, can tour this ball of rock and water with no hicups. resolv.conf is identical to whats on 7 other machines here, and they all work just fine. So how do I go about setting up a hosts file base local network? Thanks much all. Cheers, Gene

Hi folks, this is my first thread here, I just recently came aboard since I found that Armbian is the better solution for my Odroi-HC4 therefore I won't insist on checking for info and solution on the Odroid Forum. I am not very satisfied with Hardkernel, they produce excellent board with very poor OS support, looks like such critical aspect is left on the shoulder of a couple of great dudes but is not same as having a community behind; also board as the RPI demonstrated that a great OS support is better than having the most powerful hardware, is the same lesson learned by Rock64 even though I won't user Manjaro not even under torture... 😜 Armbian might a great asset for Hardkernel, never understood why they are so reticent... 🤷‍♂️ Thanks! F.

I too have encountered this issue after downloading Armbian 22.08 Jammy XFCE (Release date: Oct 28, 2022). It appears that X server is crashing on launch with a backtrace. See the attached Xorg.0.log. Searching on Google leads to the following thread and the suggestion to use mesa-git instead of the distro mesa: https://forum.pine64.org/showthread.php?tid=8915 I know it is an old thread, but it got me thinking that this may be a related and/or similar issue. At the very least it made me realize the issue is likely related to Mesa drivers, so I decided to try enabling Oibaf PPA to get the latest Mesa drivers. While doing so I came to realize that Armbian is already building images with the Oibaf PPA enabled: anderson@rock64:/etc/apt/sources.list.d$ cat oibaf.list deb [signed-by=/usr/share/keyrings/oibaf.gpg] http://ppa.launchpadcontent.net/oibaf/graphics-drivers/ubuntu/ jammy main So, I decided to instead purge out the PPA to see if the issue is only present in newer Mesa drivers: anderson@rock64:~$ sudo apt install ppa-purge anderson@rock64:~$ sudo ppa-purge ppa:oibaf/graphics-drivers anderson@rock64:~$ sudo reboot After purging the Oibaf PPA drivers I can at least get X server to start, however it is not a good solution. There are some graphical glitches such as black bands across the screen when it is redrawn in high activity cases. These black bands happen for me when I move the mouse cursor around quickly at the login screen, or when I drag a window around rapidly on the desktop. In any event, this almost certainly appears to be an issue with the rockchip_drm driver and/or Mesa driver. I don't know if this is in Mesa, Xorg or both, but it likely needs a bug filed upstream with one of those projects in order to get a fix. Xorg.0.log

I have seen some problems reporting on Rock64 / RK3328 (boots but desktop doesn't load) and Orangepi 4 (old one) not boot at all. If someone can check on this or similar devices. I can fastest tomorrow evening.

Which image exactly did you try from here https://www.armbian.com/rock64/ ?

I am having the same problem and dmesg output with my Ubuntu rock64 I am also getting errors in Xorg.log as described in What is the connection ?

after several minutes, a 3 line error message is output on 2 old original rock64's. network works, I can log in from my local net, and dmesg says: [ 35.867400] Unbalanced IRQ 47 wake disable [ 35.867422] WARNING: CPU: 0 PID: 1580 at kernel/irq/manage.c:900 irq_set_irq_wake+0x108/0x148 [ 35.867447] Modules linked in: rfkill joydev snd_soc_spdif_tx gpio_ir_recv rc_core lz4hc cdc_acm lz4 hantro_vpu(C) rockchip_vdec(C) rockchip_iep snd_soc_simple_card v4l2_h264 snd_soc_rockchip_i2s rockchip_rga videobuf2_dma_contig snd_soc_rockchip_pcm snd_soc_hdmi_codec snd_soc_rk3328 snd_soc_simple_card_utils v4l2_mem2mem snd_soc_rockchip_spdif videobuf2_dma_sg videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_soc_core videobuf2_common videodev snd_pcm_dmaengine mc snd_pcm snd_timer snd soundcore cpufreq_dt zram binfmt_misc sch_fq_codel ramoops reed_solomon pstore_blk pstore_zone ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj realtek dwmac_rk stmmac_platform stmmac lima dw_hdmi_cec pcs_xpcs gpu_sched dw_hdmi_i2s_audio gpio_syscon [ 35.867680] CPU: 0 PID: 1580 Comm: NetworkManager Tainted: G C 5.15.74-rockchip64 #22.08.6 [ 35.867693] Hardware name: Pine64 Rock64 (DT) [ 35.867699] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 35.867709] pc : irq_set_irq_wake+0x108/0x148 [ 35.867724] lr : irq_set_irq_wake+0x108/0x148 [ 35.867734] sp : ffff80000a7e3b30 [ 35.867739] x29: ffff80000a7e3b30 x28: ffff00000184d880 x27: 0000000000000000 [ 35.867757] x26: 0000000000000000 x25: 0000000000000000 x24: 0000ffffe172c0f8 [ 35.867774] x23: 000000000000002f x22: 0000000000000000 x21: 00000000ffffffea [ 35.867790] x20: ffff80000954c7c8 x19: ffff000000711200 x18: 0000000000000001 [ 35.867806] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000280 [ 35.867822] x14: ffff80000a7e3840 x13: 00000000ffffffea x12: ffff800009b1fd10 [ 35.867838] x11: 0000000000000003 x10: ffff800009b07cd0 x9 : ffff800009b07d28 [ 35.867855] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 [ 35.867870] x5 : ffff8000f501a000 x4 : 0000000000000000 x3 : 0000000000000002 [ 35.867886] x2 : 0000000000000001 x1 : 8cf7ed973ed99a00 x0 : 0000000000000000 [ 35.867903] Call trace: [ 35.867908] irq_set_irq_wake+0x108/0x148 [ 35.867920] stmmac_set_wol+0x74/0x128 [stmmac] [ 35.867985] dev_ethtool+0x1400/0x20b0 [ 35.867998] dev_ioctl+0x1fc/0x3f8 [ 35.868008] sock_do_ioctl+0xb4/0xf8 [ 35.868018] sock_ioctl+0x2d4/0x3b8 [ 35.868027] __arm64_sys_ioctl+0xa8/0xe8 [ 35.868038] invoke_syscall+0x44/0x108 [ 35.868050] el0_svc_common.constprop.3+0x94/0xf8 [ 35.868061] do_el0_svc+0x24/0x88 [ 35.868071] el0_svc+0x20/0x50 [ 35.868080] el0t_64_sync_handler+0x90/0xb8 [ 35.868089] el0t_64_sync+0x180/0x184 [ 35.868099] ---[ end trace b82369d81dab89d6 ]--- [ 147.094526] hdmi-audio-codec hdmi-audio-codec.4.auto: Only one simultaneous stream supported! [ 147.095731] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -22 [ 147.096881] ff000000.i2s-i2s-hifi: soc_pcm_open() failed (-22) [ 147.250755] overlayfs: "xino" feature enabled using 2 upper inode bits. ================== on both machines. These have a primary assignment of running octoprint as part of my printer farm and hdmi video is required. Any clues as to what will restore their video?

I have the same problem with a rock64 running the latest Ubuntu XFCE

I just did another apt upgrade on one of the rock64's that included 8 packages, some of it Xorg stuff, but the problem persists, no video on the rock64's own monitor. Both of them. They are both running well enough i can login with an "ssh -Y nameofmachine" So I have extracted a fresh copy of the dmesg error stanza, and the /var/log/Xorg.0.log generated by the reboot after the update. Attached. If that can't ID the problem, what else do you need? I see you are asking for help. I don't code well, but I'll certainly play the canary in the coal mine as a test mule. Both machines are up to date as of half an hour ago. Thanks for any help. dmesg-clipXorg.0.log.txt

Since 23 hours, 23 views, no reply's. So I have ordered a 4 pack of the latest 4gig bananna pi's, and would like to know: 1. if Armbian will work on them, and 2. If octoprint-1.8.6 can be installed in a python venv so I can get back to work on a room full of 3d FDM printers. off topic, I have been running an apt update at about 8 hour intervals on the rock64's but while error msgs are, or were displayed on the hdmi output, no xserver appears to be start-able, the hdmi display has now gone dark without its declaring a loss of signal so I have to assume it is generating a synch signal of some sort. I can ssh -Y into both from this machine 3 rooms away, but the local displays are blanked. Thank you all, take care & stay well.

further info on the x failure on rock64's. This is something I've not seen in 24 years of a linux only house. An update session on both very early rock64's killed the local video. Xorg.0.log