Search the Community

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

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?

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

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.

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.

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

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

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 ?

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

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

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.

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?

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

On Armbian Buster, rockchip (rock64), kernel 5.16.69. This was also happening on the latest backported version of 5.10, I think 5.10.72? I tried upgrading to fix it to no avail. I have a couple 8TB HDDs that I use as backups. All I did was reformat one of them as btrfs and start copying the data back over from the other (still EXT4). I tried rsync and simple cp. Without fail, a few minutes into the operation, the copy operation will hang indefinitely, and all open terminals receive these kernel messages: Message from syslogd@localhost at Oct 1 16:59:57 ... kernel:[ 339.539365] Internal error: Oops: 96000004 [#1] PREEMPT SMP Message from syslogd@localhost at Oct 1 16:59:57 ... kernel:[ 339.560387] Code: cb0100a3 cb0d015c 7100019f 9b167c00 (9adb2400) After that, every subsequent copy operation from the EXT4 drive to this new btrfs partition will hang until I reboot the rock64. However, the drive otherwise continues to work fine. fsck and btrfs scrub find no problems. The super weird thing is I can still write files, and copy a small shell script from the home folder, all just fine--but copying from the other 8TB drive will immediately hang. I have had zero issues with either drive until trying btrfs now. I'm able to rsync between them just fine when they're both EXT4. journalctl.txt specific-error.txt

Thanks for your feedback and advice. Appologies for late response, I can only post once a day as a new user. I am not using Microsoft virtualization, despite what Linux says. This issue has nothing to do with virtualization though, it's easily reproducable on bare metal with Ubuntu 22.04/Debian 11, or in docker, hyper-v, Xen, KVM, even LXC as this u-boot compilation error is before anything that LXC might not support (though this doesn't mean LXC is supported, it might fail later on for some other reason!). Upon further investigation, I did find that the compilation log file had some useful information that led to a solution. The error listed there was a ton of syntax errors and such. I've included the full log file below for anyone with the same issue who might want to actually fix the issue rather than work around it. The error I found led me to this page https://github.com/hardkernel/u-boot/issues/73. While there was no solution there, it did give me the idea to try an older OS since perhaps Ubuntu 22.04 and Debian 11 packages are too new for this old code. Turns out I was right. Using Peppermint 10 (Based on Ubuntu 18.04, I'm sure it'd work fine on Ubuntu 18.04 too) this error is gone. In order to get it to run on Ubuntu 18.04, you have to edit line 1447 of ./build/lib/general.sh to include bionic as a supported version. You also need to install libncurses-5.dev if you don't have it already or else it errors later on due to missing ncurses. I know this is obviously unsupported but if you need the u-boot compile to actually work and this isn't fixed by the time anyone else is reading this in the future, that's how I got it to work. I didn't try Ubuntu 20.04 but it could have a chance of working too since it has older packages than 22.04 but as of now, is listed as a supported version in the general.sh file. ---------------------------- Start u-boot error compilation.log ----------------------------------- == u-boot make == In file included from tools/../include/libfdt.h:54, from tools/fdt_host.h:11, from tools/imagetool.h:24, from tools/aisimage.c:8: /usr/include/libfdt_env.h:27:30: error: conflicting types for ‘fdt64_t’; have ‘uint64_t’ {aka ‘long unsigned int’} 27 | typedef uint64_t FDT_BITWISE fdt64_t; | ^~~~~~~ In file included from <command-line>: ././include/libfdt_env.h:19:16: note: previous declaration of ‘fdt64_t’ with type ‘fdt64_t’ {aka ‘long long unsigned int’} 19 | typedef __be64 fdt64_t; | ^~~~~~~ In file included from ././include/libfdt_env.h:12, from <command-line>: /usr/include/libfdt_env.h:47:24: error: expected ‘)’ before ‘x’ 47 | static inline uint32_t fdt32_to_cpu(fdt32_t x) | ^~~~~~~~~~~~ ././include/compiler.h:66:16: error: expected ‘)’ before ‘&’ token 66 | ((((x) & 0xff000000) >> 24) | \ | ^ ././include/compiler.h:66:30: error: expected ‘)’ before ‘>>’ token 66 | ((((x) & 0xff000000) >> 24) | \ | ^~ ././include/compiler.h:66:37: error: expected ‘)’ before ‘|’ token 66 | ((((x) & 0xff000000) >> 24) | \ ----------------------------- End u-boot error compilation.log ------------------------------------ Full log (LOTS more errors I left out for brevity): https://files.electrohaxz.host/file/e3872aa444605cab978c45b683c00b44/compilation.log Incase something is missing, here's an archive of the entire debug folder contents for the u-boot compilation error (all logs) https://files.electrohaxz.host/file/f1df43da7dbaffb65bd634e7ba1e2c07/uboot-err-logs.7z Now my issue is unrelated to u-boot. The whole reason for recompiling was to enable kvm support (and preferably support lxc too but didn't attempt that yet), however after enabling KVM in the compile options, the compile fails with the below error. Is this something you or someone else would be able to help with? I'm not too sure since this is a CSC board and I don't want to ask too much. I figured there's a reason KVM isn't enabled in the kernel by default on this platform, despite it being enabled on others like rock64. Perhaps this is something unsolvable for one reason or another, I don't know. Any help regarding this would be greatly apprecaited as I've got about $1000 worth of these boards in a cluster and without lxc or kvm, I'm not sure what I can use them for unfortunately. If this isn't something I can get help on then I understand too. I would also be willing to donate a bit to whomever could help get kvm and lxc working in this kernel if I can donate with crypto. If anyone willing to help needs a development system to build on if you don't have your own, I can also provide remote access to a server with any OS of your choice and plenty of compute and fast networking for that for as long as needed (for free, of course!). I can also provide remote access to as many nano pi fire 3's as you need if that's needed for any reason. ---------------------------- Start KVM error Output.log --------------------------------------- arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:574:9: error: implicit declaration of function ‘arch_timer_get_kvm_info’; did you mean ‘arch_timer_get_cntkctl’? [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[1]: *** [arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.o] Error 1 make: *** [arch/arm64/kvm] Error 2 [ error ] ERROR in function compile_kernel [ main.sh:595 -> main.sh:489 -> compilation.sh:509 -> general.sh:0 ] [ error ] Kernel was not built [ @host ] [ o.k. ] Process terminated ----------------------------- End KVM error Output.log ---------------------------------------- Full log: https://files.electrohaxz.host/file/338487ce6b7e665d521325acadc0791a/output.log ---------------------------- Start KVM error compilation.log ----------------------------------- == kernel == arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c: In function ‘kvm_timer_hyp_init’: arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:574:9: error: implicit declaration of function ‘arch_timer_get$ info = arch_timer_get_kvm_info(); ^~~~~~~~~~~~~~~~~~~~~~~ arch_timer_get_cntkctl arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:574:7: warning: assignment to ‘struct arch_timer_kvm_info *’ f$ info = arch_timer_get_kvm_info(); ^ cc1: some warnings being treated as errors make[1]: *** [arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.o] Error 1 make: *** [arch/arm64/kvm] Error 2 make: *** Waiting for unfinished jobs.... fs/proc/task_mmu.c: In function ‘show_smap.isra.13’: fs/proc/task_mmu.c:764:7: warning: ‘last_vma’ may be used uninitialized in this function [-Wmaybe-uninitialized] bool last_vma; ^~~~~~~~ ----------------------------- End KVM error compilation.log ------------------------------------ Full log: https://files.electrohaxz.host/file/e555ae72e83a95e2909bd5bc448909e3/compilation.log Incase something is missing, here's an archive of the entire debug folder contents for the KVM error (all logs) https://files.electrohaxz.host/file/6afc42fcb211b8562eb73040c352a652/kvm-err-logs.7z

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?

I wonder what the best desktop replacement might be. I'm in need for a stable and secure desktop replacement that is energy saving and capable of dooing office work, browsing the web and even playback videos from youtube and prime video. 4K isn't necessary but I want at least 720p or 1080 fullscreen. If possible: No internal spi / eeprom / flash memory. I want the firmware to be loaded from a USB Storage / SD Card that gets hardware write protected after the first setup. Like a live distro from dvd so that there is no risk of getting infected by rootkit / bad firmware ever. Most current gen SoC offer built in flash memory. Older ones like Rock64, Pi3 and even the newer Odroid C4 doesn't seem to have built in flash memory. Which might suit my needs. The odroid c4 has been my favorite choice but a lot of people complained about several bugs and poor os support in general - David L wrote: "It's now Jan 2021 and it's a shame that with this excellent hardware the OS situation is still very poor with many issues such as freezing regularly, black/frozen screens if the monitor goes into standby mode while you are away, and many more. There are manual fixes for some of them, but the level of OS support shouldn't still be this poor and left to users to identify fixes. It was the same with the U3 and (less so with the) C2, and unless HK provide more OS support, they will find people moving to other platforms (no mattter how good their h/w is!)." Amazon Prime playback compatibility isn't necessary Fullscreen Youtube 720p playback capatibility is mandatory Beeing able to use a live distro is mandatory Im really looking forward to your suggestions. Best regards

Answering my own question here for other folks. This works https://dietpi.com/forum/t/no-usb3-after-apt-upgrade-rock64/6439/29 apt install linux-dtb-current-rockchip64=21.08.2 linux-image-current-rockchip64=21.08.2 apt-mark hold linux-dtb-current-rockchip64 linux-image-current-rockchip64 I also let @TonyMac32Tony Mac-n-cheese knows on discord. I'm not sure who would find kernel deltas and fix this.

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

I just cannot access spi on my Rock64. I read a couple posts of it but none works out for me I'm running Armbian 22.05.3 Focal with Linux 5.15.52-rockchip64 on it. Tried enabling spi-jedec-nor and spi-spidev overlay, but with none of them I get output when executing ls /dev/spi*. Is it maybe a hardware issue, reading this post suggests that to me: https://forum.pine64.org/showthread.php?tid=5473&pid=34616#pid34616 But I cannot make much sense out of it. Can anyone help me get spi working?