eselarm

@NOBL You can select text of someones post and then a small popup appears; If you click that, a reply/edit field is provided. It also took me some time before I discovered, maybe it was a browser issue or webblocker before I don't know. Related to it, I also don't know how to create 'hidden' text files so no endless logs or so. Anyway, on the topic: I see indeed VM is only x86-64 focused and also no Linux default build-in virtualizer, only external/commercial stuff like VMware and Windows/Mac. So for nextcloud, it is worse then for HAOS as I see it now. For HAOS, there is some Aarch64 VM image hidden somewhere on github, no documentation, but it works, does update well. It is same principle as for x86-64 VM images, so for me, having used standard Linux virt-manager (libvirtd/QEMU/KVM) for several years after VirtualBox and after VMware, it was easy to get running and as HA has a good backup-restore option, you get perfectly the same In a Aarch64 VM hosted on my ROCK5B for example as something running on old Intel Atom computer (also as VM by the way). So I would consider the easy 'nextcloudpi' and ready made images gone; You have to dig deeper and do more yourself, so looking at all the lower level components like PHP versions etc that fit a certain version. That is independent of which ARM SBC. Nextcloud is high-level software, there is no dependency on HW pins or GPIO or videocodecs etc. If there are Aarch64 images, you have to look at how they are created. I see from other post that there is ncp command, so what does that do? If you stick to 'images', you will indeed have a problem. The only relevant difference between Odroid and Raspberry or other Aarch64 SBC is the bootloader and kernel. Raspberry is the worst as they also do many changes to Debian userspace which for example from bookworm to trixie ruined my networking setup, so I blocked specific things (netplan stuff) and went back to Debian versions. Also RPi5 still cannot run standard Debian. If you want standards, make sure your HW supports UEFI, same as every PC/MAC does. See https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file#supported-platforms I have this on ROCK5B and NanoPi-R6C and it is like a PC. You have to install it yourself of course, it is not pre-installed like is the case on a PC. But after installed, it is like a PC. Both those boards I have bought with metal case/heatsink, so no fans. Faster than a RPi5 and M.2 M-key slot on-board, so can use standard Samsung NVME or so. Also, the current/edge Armbian rockchip64 kernel runs in/as a VM, which makes it super flexible for tests but also for 24/7 doing real things. I installed grub-efi and then it boots as VM (assumuing 2 partition scheme). For Odroid (Amlogic SoC) I would expect the same. If not, install linux-image-arm64 in addition and use that kernel.

There are schematics available for this device, so one could get a hint from those, but depends if you have electronics background or not. To me it seems that higher level software in Debian/Linux enables power management handling all the way using info it gets from the power management chip/circuitry. You can guess that for this device, same as smartphone, battery operation is considered primary/essential, so decision is 'low-batt' and shutdown. I have a BananaPi M1 that also has LiPo charging, but that is DIY soldereing, so no OS component bothers with not-connected cell, but if a cell is connected/soldered which I did, is charges and runs on that cell if microUSB PSU (they call it 'AC' in the chip signal names) is disconnected, although its SATA port is unpowered then. Runs Armbian Trixie CLI only (eth + serial console). An old business HP 2-core laptop that I got without battery and HDD runs fine on just the original HP power adaptor (has 3rd wire for some genuine HP charger purposes). For USB-C powered devices, there might be many things to deal with, e.g. my ROCK5B after un-boxing goes in a bootloop with a RPI5 PSU, was/is know, so I feed it with own 12V USB-C pig-tail. For the Pinebook, it might be that the 5V is perfectly 5.000V but drops to 4.900V or so in spikes under load, so the typical 5V SBC powering issue well-known from RPi and other cheap SBCs that cannot handle >5V USB PD voltages. The Pinebook might do well if you fake the battery, so look at colored wire/connector. I have used that several times in the past decades. The yellow wire might be for temperature so besides a proper voltage on black and red, you also need to do something with the yellow wire I guess. It also might be that is you skip/disable the parts of software that do power management handling, that it runs fine. So I would boot/run the 'image' of the pinebook in a systemd-nspawn container or libvirt VM (at least the user space) and see what is what. Maybe it is something like purge 'laptop-tools' package or so, or blacklist the kernel module for power management.

What is easiest depends on the situation. If you feel comfortable enough to use dd to write bootloader, I just downloaded the -edge package from the beta apt package pool, extracted the .bin file and wrote it to correct location on SD-card, after saving the first 32k sectors also with dd to a backupfile. Then reboot and you know it. The qemu experiment was to boot directly from U-Boot to Btrfs raid1 filesystem, it took a lot of time browing through U-Boot config/compile options. Better/formal method is to install -edge package, it will remove -current package, then use armbian-config to write the bootloader explicitly.

OK, it seems your SPI-flash is empty, so not used and skipped. I start to remember I think; ROCK5B -current is quite old and not from denx.de (or 'mainline') so I picked -edge, but I think I never wrote it to SPI, instead I have this in SPI: https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file You need grub-efi or other efi capable and configured bootloader (hide boot.scr, add ESP partition) root@rock5b:~# strings /usr/lib/linux-u-boot-edge-rock-5b/u-boot-rockchip-spi.bin | grep "U-Boot SPL" U-Boot SPL 2024.04-armbian-2024.04-S830c-P0000-H1056-Vdfa5-Bb703-R448a (Jun 08 2025 - 03:38:17 +0000) My ROCK5B is 24/7 server, I won't reboot and do checks now, up to yourself to dig deeper and see how various versions are build. I remember there is a config option w.r.t. this 1 sec timeout, that I saw when building qemu arm64 u-boot a year ago. I currently have blocked u-boot and armbian packages, but will maybe configure/build for ROCK3A 2025.10, but that is completely other topic/issue.

I see from https://github.com/nextcloud/nextcloudpi/releases that 'pi' is sort of a synonymy for 'ARM SBC' or pre-installed images. 'pi' is great but a problem as it is not generic arm64 so every SBC flavor needs a 1GByte zip image just for a different kernel and bootloader. Same as long time ago I used a 'pi' script to get Node-RED installed in an x86 Debian Bullseye Virtual Machine (so just 'Debian' actually), I would focus on generic solutions. Armbian is doing very well w.r.t. alignment and portability, so the SoC or SBC does not really matter, as long as it is compliant with Debian ARM64. For Node-RED on Opensuse-Tumbleweed ARM64 I needed to hack the script a bit to fake a compliance check, but with that, it also worked. It saved an enormous amount of effort re-installing OS etc. So bottom line is, maker sure you don't lock yourself into a certain SBC or SoC, but make sure it is standard generic ARM64 (or standard x86-64, which is already the case for years) A way to keep your current installation is to 'virtualize' it: What runs on the Odroid or RaspberryPi or other SBC from SD-card or eMMC or NVME or SSD can be made EFI bootable and then it will run as virtual machine on the same SBC or other new/faster SBC of course as well. I have done this for RPI3B functions -> RPI4B in the past (also 32-bit VM in 64-bit host, Pi-Hole for example) and this year again to replace RPi4B-8GB with ROCK5B-16GB. It is beyond the scope of this topic, but start with installing 'virt-manager' and try to boot and Armbian-UEFI image/instance. Or see: https://github.com/nextcloud/vm I haven't used 'cloud' since owncloud, but right now, if I would certainly start with a VM. Same for e.g. HAOS, runs fine in a VM on ROCK5B. You do not need proxmox, all is build-in in Linux already.

I usually fight a bit the default 80x25 serial terminal sizing (KDE konsole) via 'screen /dev/ttyUSB0 1500000', but tools like MidnightCommander can be used. Certainly all standard CLI stuff and copy-paste. So just some commands: apt list --installed linux-u-boot-rock-5b* dpkg -L linux-u-boot-rock-5b-edge cat /usr/lib/u-boot/platform_install.sh cat /dev/mtdblock0 > /tmp/spidump strings /tmp/spidump | grep -i U-Boot

If you have used RadxaOS before there might be an older U-Boot variant in SPI-flash and at least on ROCK3A SPI take preference over SD-cards, so the Armbian U-Boot from SD-card is not use. AFAIR Radxa OS ROCK5 U-Boot does not have the 1 sec autoboot timeout and also uses extlinux script and not bootcmd. But I might mix-up versions and platforms. So rewrite SPI-flash from Armbian is option to fix it.

Simple GPIO toggling has been a long term issue and it is clear to me that it need continued attention. I only use pin toggle on RPi1 and NanoPi-NEO, so BCM2835 and AllwinnerH3. I use generic Linux gpiod, still a bit a workaround for really proper handling, but it is OK for non-critical tasks at home. I used original WiringPi on RPi before (from Gordon), but many forks now. See also: https://forums.raspberrypi.com/viewtopic.php?t=369361 'latest' seems to be here: https://github.com/WiringPi/WiringPi?tab=readme-ov-file Note what is written under Ports w.r.t. Python. I guess Werner's guess is correct. I am not good at Python so prepared a bit for own C-code implementation, also w.r.t. high speed PWM. On AllwinnerH3 running Armbian Trixie, using the lgpio examples was easy to toggle a pin. I currently have Domoticz doing it, so also easy MQTT messaging, but it is overkill and also Domoticz build for ARMv6 is not available anymore (needed for RPi0/1), so already replaced that.

I just did a simple test that always worked on Intel CPUs with with logitech C310 on ROCK5B with 6.1.115 kernel /usr/share/jellyfin-ffmpeg/ffmpeg -y -hide_banner -f video4linux2 -input_format yuv420p -video_size 640x480 -framerate 30 -i /dev/v4l/by-id/usb-046d_081b_9061E8E0-video-index0 -map v -c:v h264_rkmpp -f mpegts webcam.ts Output file plays fine, good motion, same as if I use normal ffmpeg and just non-accel h264 codec, although CPU load is then about 20% for the ffmpeg process, while when using rkmpp it is below 1% For higher resolution, I think C310 internal MJPG is needed, but that is normal, USB2 has limited bandwidth.

There should be a big difference in speed and powerconsumption; As I indicated in earlier post, edge kernel has no video encoding working, so at least is is SW encode. Debian/standard ffmpeg for aarch64 only had/has v4l2m2m, no dedicated RKMPP also no old OpenMAX rpi methods (in the past). I think this works for Qualcomm SoCs, but no others I am aware of. If you use RK35xx RKMPP I see almost 5x real-time speed for 1080p50 and low CPU load. See example below: root@rock5b:~# ffmpeg -hide_banner -codecs | grep -e h264_v4l2m2m -e h264_rkmpp DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_v4l2m2m h264_cuvid) (encoders: libx264 libx264rgb h264_nvenc h264_v4l2m2m h264_vaapi h264_vulkan) root@rock5b:~# /usr/share/jellyfin-ffmpeg/ffmpeg -hide_banner -codecs | grep -e h264_v4l2m2m -e h264_rkmpp DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_v4l2m2m h264_rkmpp h264_cuvid) (encoders: libx264 libx264rgb h264_nvenc h264_v4l2m2m h264_rkmpp) root@rock5b:~# /usr/share/jellyfin-ffmpeg/ffmpeg -y -hide_banner -c:v hevc_rkmpp -i /lan/record/2025-11-04-NPO-1.ts -map v -c:v h264_rkmpp -f mpegts /dev/null Input #0, mpegts, from '/lan/record/2025-11-04-NPO-1.ts': Duration: 06:59:01.58, start: 14798.887378, bitrate: 4058 kb/s Program 1 Metadata: service_name : NPO 1 service_provider: KPN Stream #0:0[0x1b63]: Video: hevc (Main) ([36][0][0][0] / 0x0024), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn Stream #0:1[0x1b64](dut): Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp Stream #0:2[0x1b69](dut): Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 Hz, stereo, fltp (visual impaired) (descriptions) Stream #0:3[0x1b65](dut): Subtitle: dvb_teletext (libzvbi_teletextdec) ([6][0][0][0] / 0x0006), 492x250 No Program Stream #0:4[0x12]: Data: epg Stream mapping: Stream #0:0 -> #0:0 (hevc (hevc_rkmpp) -> h264 (h264_rkmpp)) Press [q] to stop, [?] for help Output #0, mpegts, to '/dev/null': Metadata: encoder : Lavf61.7.100 Stream #0:0: Video: h264 (High), nv12(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 2000 kb/s, 50 fps, 90k tbn Metadata: encoder : Lavc61.19.101 h264_rkmpp ^C[out#0/mpegts @ 0xaaaaea74fce0] Error writing trailer: Immediate exit requesteds speed=4.86x [out#0/mpegts @ 0xaaaaea74fce0] Error closing file: Immediate exit requested [out#0/mpegts @ 0xaaaaea74fce0] video:61287KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 6.096897% frame=12559 fps=244 q=25.0 Lsize= 65024KiB time=00:04:11.16 bitrate=2120.9kbits/s speed=4.87x ^C^CReceived > 3 system signals, hard exiting

My understanding is that v4l2request is for vendor kernel that does RKMPP, so that V4L2 API is available for browser or mpv to play video, so decoding only. I have not focused on that, although HEVC HW accelerated decoding would be really welcome. W.r.t. camera capture and encoding, I only used RPI1 (legacy firmware V4L2 stack) and RPi3/4 (libcamera). Many variants, but is it possible to get uncompressed frames from a camera, push it through the h264 HW encoder (h264_v4l2m2m) and then to some RTSP sink (MediaMTX) to show it as WebRTC in a browser. That is with RPi kernel and RPi ffmpeg, so 'vendor' solution. Although V4L2, it won't work with a standard/mainline Debian kernel yet AFAIK. For Rockchip, I use ffmpeg that comes with jellyfin to do transcoding (HEVC->H264). It works fine with 6.1.115 vendor kernel, I have not used it for camera. It might miss certain things w.r.t. V4L2 controlling camera attributes. Below is what I get on a NanoPi-R6C (RK3588s, Trixie). You can see only JPEG encoder is available. root@ranc:~# uname -a Linux ranc 6.18.0-rc3-edge-rockchip64 #1 SMP PREEMPT Sun Oct 26 22:59:49 UTC 2025 aarch64 GNU/Linux root@ranc:~# ls -al /dev/media* crw-rw----+ 1 root video 238, 0 Nov 4 13:53 /dev/media0 crw-rw----+ 1 root video 238, 1 Nov 4 13:53 /dev/media1 lrwxrwxrwx 1 root root 6 Nov 4 13:53 /dev/media-dec0 -> media0 lrwxrwxrwx 1 root root 6 Nov 4 13:53 /dev/media-dec1 -> media1 root@ranc:~# media-ctl -d 0 -p Media controller API version 6.18.0 Media device information ------------------------ driver hantro-vpu model hantro-vpu serial bus info platform:fdba0000.video-codec hw revision 0x0 driver version 6.18.0 Device topology - entity 1: rockchip,rk3588-vepu121-enc-sou (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video1 pad0: SOURCE -> "rockchip,rk3588-vepu121-enc-pro":0 [ENABLED,IMMUTABLE] - entity 3: rockchip,rk3588-vepu121-enc-pro (2 pads, 2 links) type Node subtype Unknown flags 0 pad0: SINK <- "rockchip,rk3588-vepu121-enc-sou":0 [ENABLED,IMMUTABLE] pad1: SOURCE -> "rockchip,rk3588-vepu121-enc-sin":0 [ENABLED,IMMUTABLE] - entity 6: rockchip,rk3588-vepu121-enc-sin (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video1 pad0: SINK <- "rockchip,rk3588-vepu121-enc-pro":1 [ENABLED,IMMUTABLE] root@ranc:~# media-ctl -d 1 -p Media controller API version 6.18.0 Media device information ------------------------ driver hantro-vpu model hantro-vpu serial bus info platform:fdc70000.video-codec hw revision 0x0 driver version 6.18.0 Device topology - entity 1: rockchip,rk3588-av1-vpu-dec-sou (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: SOURCE -> "rockchip,rk3588-av1-vpu-dec-pro":0 [ENABLED,IMMUTABLE] - entity 3: rockchip,rk3588-av1-vpu-dec-pro (2 pads, 2 links) type Node subtype Unknown flags 0 pad0: SINK <- "rockchip,rk3588-av1-vpu-dec-sou":0 [ENABLED,IMMUTABLE] pad1: SOURCE -> "rockchip,rk3588-av1-vpu-dec-sin":0 [ENABLED,IMMUTABLE] - entity 6: rockchip,rk3588-av1-vpu-dec-sin (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: SINK <- "rockchip,rk3588-av1-vpu-dec-pro":1 [ENABLED,IMMUTABLE]

Quick retest in the container if I also install normal Debian kernel: root@ranc:~# apt install linux-image-arm64 wireguard Installing: linux-image-arm64 wireguard Installing dependencies: linux-image-6.12.48+deb13-arm64 wireguard-tools Suggested packages: firmware-linux-free linux-doc-6.12 debian-kernel-handbook openresolv | resolvconf

But why the Real-Time kernel and not the normal (linux-image-arm64) kernel package? I actually did run it as a systemd-nspawn -bxD <btrfs read-only snapshot> , so Armbian as container and host vanilla Debian. The actual kernel is then 6.12.48+deb13-arm64, but indeed the Armbian userspace (rootfs tree) has a few others/custom kernels installed only, so standard kernel package is missing.

Strange thing is that on Armbian Trixie (arm64), if I do 'apt install wireguard', I get as dependencies: linux-image-6.12.48+deb13-rt-arm64 linux-image-rt-arm64 wireguard-tools On vanilla Debian Tixie (arm64), only wireguard-tools Even if I remove/disable all armbian sources, same problem. Anyway the fix/cleanup that works for me (RK3588 platform): apt purge linux-image-6.12.48+deb13-rt-arm64 linux-image-rt-arm64 apt-mark manual wireguard-tools

You seem to have the older obsolete special RPI5 build, that doe not exist anymore, it is just 1 RPI build called 'rpi4b' So remove armbian-bsp-cli-rpi5b-current as well apt update dpkg --remove --force-all libraspberrypi0 armbian-bsp-cli-rpi4b-current armbian-bsp-cli-rpi5b-current apt --fix-broken install apt install armbian-bsp-cli-rpi4b-current