eselarm

That RK356x would not be much faster than the H618 I think and "sunxi kernel" is 32-bit, I assume you use and mean 64-bit. DKMS always needs attention (in my experience), so I am happy I made/have my computers/boards such that I do not need it. actually, this topic made me do: apt purge dkms -y, as last week dist-upgrade from Bookworm to Trixie/Testing also had some issue (only a warning, not fatal) regarding DKMS. In the past I used it for some SDR hardware module, but for WiFi USB dongles I simply have a red line: If no mainline kernel integrated code, I do not use is. Also what Igor points to, that stick you have is just very low wireless performance. Use RJ45 or buy good WiFi module I would say. zfs-dkms has no hardware/vendor origin, so that is less of a problem, but note that for cheap low end SBC hardware, Btrfs also works fine and is in the Linux kernel so no special care needed. Also works fine on old ARMv6 Raspberry Pi0/1 including Zstd on-the-fly compression etc. You could create an 2-parttiton image (and U-Boot blob will be between partition table and 1st partition). Use Btrfs as rootfs and also install vanilla Debian kernel and GRUB EFI. Tag 1st as 0xEF00 (ESP) type. Then that image can run as Virtual Machine (hardware accelerated) on all ARM64 SoCs and also emulated on fast x86-64 PCs. Run armbian build inside that VM. I did that for 32-bit Allwinner as I have NanoPi-NEOs, don't have 64-bit Allwinner SoCs. So then easier experiementing and developing and you also have kernel log via virtual tty. Still make sure you have real serial cable/console for that H618.

I upgraded my ROCK5B in-place from Armbian Bookworm beta to Armbian Testing/Trixie beta and it turns out that no Ambian packages are seen (so not updated). The Debian Trixie packages do upgrade, as for example I just saw while doing full-upgrade: libavif16:arm64 (1.2.1-1.2) over (1.2.1-1.1) ... I thought something with my install, but also downloaded 'Armbian_25.8.0-trunk.50_Rock-5b_trixie_vendor_6.1.115_minimal.img' yesterday and it has the same issue (quick test via systemd-nspawn container on loopdev mounted image). My goal is at least to figure out what is best bootloader and kernel for the ROCK5B. So far I simply copied/cloned Armbian Bookworm rootfs from ROCK3A+NanoPi-R6C and did some ROCK5B specific changes like U-Boot, but not much more and it actually is already good enough. But before the ROCK5B becomes a 24/7 headless workhorse with long uptime, I thought better to prepare/check for newer Linux or potential issues. I already upgraded some other devices from Bookworm->Trixie and that is quite an improvement, for example KDE 6 performs much better/nicer than KDE5 in Bookworm. It currently uses U-Boot 'edge' and 'current' kernel and very important for me, both the 'vendor' and 'mainline current/edge' overlay for SERDES multi-PHY SATA on the M.2 E-key work (and also the NVMe keeps working). I need to drill a hole in the Radxa aluminum cooling case for the SATA cable (and serial console cable), that needs some time first. I can build and install U-Boot and kernel etc manually of -course, but i wonder why Armbian packages are not visible. Is it as expected or is something wrong? I assume it is just too early yet and that it is work in progress. I think maybe policies are an issue, but don't understand what it could be. Maybe someone has a hint. root@rock-5b:~# apt policy Package files: 100 /var/lib/dpkg/status release a=now 500 http://deb.debian.org/debian trixie/non-free-firmware arm64 Packages release o=Debian,a=testing,n=trixie,l=Debian,c=non-free-firmware,b=arm64 origin deb.debian.org 500 http://deb.debian.org/debian trixie/non-free arm64 Packages release o=Debian,a=testing,n=trixie,l=Debian,c=non-free,b=arm64 origin deb.debian.org 500 http://deb.debian.org/debian trixie/contrib arm64 Packages release o=Debian,a=testing,n=trixie,l=Debian,c=contrib,b=arm64 origin deb.debian.org 500 http://deb.debian.org/debian trixie/main arm64 Packages release o=Debian,a=testing,n=trixie,l=Debian,c=main,b=arm64 origin deb.debian.org 500 https://beta.armbian.com trixie/trixie-desktop all Packages release o=Armbian,a=trixie,n=trixie,l=Armbian,c=trixie-desktop,b=all origin beta.armbian.com 500 https://beta.armbian.com trixie/trixie-desktop arm64 Packages release o=Armbian,a=trixie,n=trixie,l=Armbian,c=trixie-desktop,b=arm64 origin beta.armbian.com 500 https://beta.armbian.com trixie/trixie-utils all Packages release o=Armbian,a=trixie,n=trixie,l=Armbian,c=trixie-utils,b=all origin beta.armbian.com 500 https://beta.armbian.com trixie/trixie-utils arm64 Packages release o=Armbian,a=trixie,n=trixie,l=Armbian,c=trixie-utils,b=arm64 origin beta.armbian.com 500 https://github.armbian.com/configng stable/main arm64 Packages release o=armbian.github.io/configurator,n=stable,l=armbian.github.io/configurator,c=main,b=arm64 origin github.armbian.com Pinned packages:

Do they use the same U-Boot or different version? It could be the server image is just composed in a faulty way, some detailed failure somewhere. I would build something for the specific SBC myself or copy the boot area from the HA image into your image/emmc. Or maybe wipe it an use an SD-card with only a U-Boot blob that you want or build yourself maybe from latest U-Boot denx.de. I have done that for QEMU variat, also did some non-standard changes and that works. In a working Armbian, I have checked/installed 3 variants (vendor, current, edge) and EDK3-UEFI for my ROCK5B and then also switching kernels. No eMMC, but only SPI-flash using flashcp and dd for SD-card. But that is Rockchip, Amlogic I do not know, do not have.

@deskwizard I don't know why I refer to OPi5Max, maybe I had other tab/topic open or so, but it is clear that it is about the OPi5. Now I have the ROCK5B, just cloned the Armbian Bookworm from ROCK3A but did not write SPI yet. Power up with fixed 12V in USB-C and from SD-card with Armbian rock5b vendor U-Boot. rootfs from NVMe, SATA overlay enabled for 3.5inch HDD. 5 audio cards: root@rock5b:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: rockchiphdmi0 [rockchip-hdmi0], device 0: rockchip-hdmi0 i2s-hifi-0 [rockchip-hdmi0 i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: rockchiphdmi1 [rockchip-hdmi1], device 0: rockchip-hdmi1 i2s-hifi-0 [rockchip-hdmi1 i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: rockchipdp0 [rockchip-dp0], device 0: rockchip-dp0 spdif-hifi-0 [rockchip-dp0 spdif-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 4: rockchipes8316 [rockchip-es8316], device 0: dailink-multicodecs ES8316 HiFi-0 [dailink-multicodecs ES8316 HiFi-0] Subdevices: 0/1 Subdevice #0: subdevice #0 card3 (unlisted) is HDMI-input I think, but disabled all in KDE settings tray except the 3.5mm plug ('headphones'). No further settings or volume change, mpv playing an mp3 instantly. I will likely do/test with 6.15 edge, also maybe 6.12 current (and other U-Boots as well). But first several mechanical/cooling things to tweak, need to drill/cut a hole for the SATA connector in the cooling metal I think.

If Allwinner does not provide C-source code (kernel, libs, ffmpeg, etc) for recent Linux, I consider it as is; no encoding on Allwinner SoCs. I have several H3 boards, I also dreamed that I once maybe could use that for HEVC->H264 transcoding (low power 24/7 multiple TV channels) but it is not happening. I spent a lot of time to get it working on Pi4 and that breaks at various distro updates or just kernel updates. But RPL then hacks/fixes it in their custom ffmpeg, but it is only Pi4 and also limited, Pi5 has no HW encoding so even they as biggest SBC company give up on it I would say. Rockchip and Intel have fairly easy out-of-the-box solutions, but both not V4L2m2m.

The NanoPi-R6C (that I have) has an extra USB-C female connector, so the chip is already on the board. You just need a USB cable (so just wires with USB signal levels) to connect to laptop or any computer with USB, even smartphone. RS232 is other voltage levels, long distance as well, so don't expect it to be spec compliant. USB is 5 meters. I think 1.5 Mbps is simply out of scope for RS232/DB9. Maybe netconsole is something you could use.

My ROCK5B is still at customs or package handling company, but I just did a quick test on my ROCK3A w.r.t. 3.5mm audio. It is headless running multi-user.target (NAS/server), Armbian Bookworm with beta repo. But it has KDE installed, so if I would do 'sudo systemctl isolate graphical.target', it flips to KDE Plasma5 GUI (that is what I do on NanoPi-R6C currently, it is cloned from there). I did manually put Radxa 2017 dated U-Boot blob in SPI-flash, so bootfs+rootfs from NVMe and also has native SATA on M.2 E-key slot. I full-upgrade every now and then (via ssh). Via ssh as normal user, I started playing some opus file with mpv, then plugged in my good old Sennheiser headset and simply good audio. See commands below. alsamixer shows a lot of I/O hardware, like I2S etc, but also some port that is or must be the 3.5mm (HP is that I think). I did not change settings. In pulsemixer I saw 2 stereo output devices, it should be HDMI and the audio chip RK809. I did disable one to 'off', (random guess, maybe not needed, hdmi off is what I aimed for) Also good to know that I removed/disabled pipewire, I still get a warning from mpv, something with 'pw.conf', but pulseaudio is used (forced that once in the past actually). user@rock3a:~$ uptime 09:45:33 up 18 days, 17:23, 2 users, load average: 0.66, 0.49, 0.46 user@rock3a:~$ uname -a Linux rock3a 6.1.115-vendor-rk35xx #1 SMP Thu Apr 24 23:11:15 UTC 2025 aarch64 GNU/Linux user@rock3a:~$ alsamixer user@rock3a:~$ pulsemixer The OPi5Max might have completely different audio chip and/or bindings, then of course the test with ROCK3A is maybe irrelevant. But anyway, I want to know if I can use 3.5mm audio or not. I use(d) it on RPI4B with does not even have a proper audio chip. I have some background pulseaudio user .service started, that works great as audio sink on other computers.

From Bullseye to Bookworm Debian went from pulseaudio to pipewire. I spent a lot of time to remove/disable pipewire as the pipewire-pulse emulation was/is? not doing networked pulseaudio properly and I use that extensively. Opensuse Tumbleweed as rolling release does not have this issue, it keeps working. It also keeps working if you do in-place upgrade from Bullseye to Bookworm (what I normally do), but I started with fresh Armbian Bookworm downloaded image and can't get networked audio working (a must on a NanoPi-R6C with no audio HW). Now I would not be surprised at all if the combination of Armbian (Debian) Bookworm with added new KDE (beta) repo external to Debian introduces another complex issue w.r.t. audio, even locally. If Armbian (Ubuntu) Noble, then challenge is even bigger. I had too many Ubuntu issues, so went back to Debian. I have not tested 3.5mm audio when I tested KDE Neon image on my ROCK3A (ran it only for 15 minutes as planned use-case was/is headless server), but in a week I will get a ROCK5B and I will use that as Desktop for some time I guess. Plan is to just take the Samsung NVMe (10 partitions, multiple OSses) out of my NanoPi-R6C and basically only change .DTB loaded (i use extlinux.conf own scripted) and some U-Boot binary on otherwise blank SD-card and then bump that in-place to Testing/Trixie (using Btrfs snapshots as safety fallback). That has KDE Plasma 6.3 AFAIR from my tablet/laptop and it won't change much I guess (Tumbleweed is 6.3.4 currently). Then it is matter of using/checking alsa and/or pulseaudio and/or pipewire tooling what is going on. As indicated, existing pulse-servers (e.g. NanoPi-NEO with SPDIF to my amplifier) work and are found and can be selected via pulseaudio tray icon, including also local USB-audio on my N100 for example. So I personally would likely remove all external package repos and make it clean Armbian Trixie. If you want to contribute to KDE development, then keep KDE Neon I guess.

I always liked the Marvell ARM SoCs because of their many high-speed I/O, but never bought one as the main CPU(s) were always behind w.r.t. raw computing performance, compared to RPi4 BCM2711 or Intel J1900. Ebon Upton of RPL once stated they won't do SATA. Instead they made an own I/O chip and some own ISP silicon design for the RPi5. It is because the focus on digital signage, so computing devices with screens and cameras. For many home-users it means the struggle goes on. I only use my RPi4 with Samsung SSD for fast local I/O (VMs etc), but what a trouble with that whole VIA PCIe-USB3 chip design (you extra need external power in the end). And look at how many people still want to build a NAS with a Pi; So BCM271x-PCIe<=>PCIe_USB3chip<=cable=>USB3_SATAchip<=cable=>HDD(s)/SSD. Or some 'HAT' via yet another proprietary extra flatcable. And then not to forget the powering of such a setup, need 12V, RPi can only accept 5V. I think worlds big IT companies aim for cloud, central storage, your data, your privacy, so principles and methods to store your own data locally at home seem like a relative niche. Not that non-tech people don't know what NAS and backup etc is, but automatic cloud for laptops and smartphone is so easy. Then the other issue is that 4 or 6 or even 10 or 12 SATA ports mostly imply many 3.5inch HDD which need then 100W or so, so the 'low-power ARM' is irrelevant. And people seem to want RAID, many still think that is also good backup. What I also noticed as problem with older ARM SoCs it that for example the Marvell 88F6828 in Helios4 is 32-bit (dual Cortex-A9). Modern filesystems are more tailored for 64-bit native. For example, Btrfs does not support >8TiB in 32-bit, and because of its CoW fundamentals, it can also hit that limit with <8TiB after many years of usage (or lots of 'balancing'). So you want a 64-bit CPU/OS. I have a BananaPi M1 still, also same as Helios4 2x Cortex-A9, but only 1 SATA2 connector. I still like that board, it runs Armbian 6.12.x now and I use it to export raw /dev/sda (8TB Seagate SMR) via nbd-server as Linux block device. That works fine with 32-bit, the limit is mostly random I/O speed due to SMR and being a HDD. If I do LVM, LUKS, Btrfs (Zstd compression) remote on top of nbd-client on a NanoPi R6C RK3588s, it works without noticing the Gbit ethernet in between. If I replace the BananaPi M1 with a Radxa ROCK 3A (on-chip SATA), same behavior more or less, although It can also run the whole 'NAS' stack on its own RK3568. Only disadvantage is then that on-the-fly Zstd compression is a bottleneck. So that made me order a ROCK 5B (RK3588), that has comparable I/O connectors (M.2 M-key for NVMe, M.2 E-key for a SATA passthough connector). I also ordered a ASM1166 M.2 M-key, so I can have the same functionality as old power hungry Intel PC with 6-SATA for tests/fallback. Note that for my main 24/7 NAS (the ROCK 3A system now) I keep a limit of 8TB, that means I don't buy new bigger HDD and only 1 is enough. Caching is done with LVMcache on the NVMe. If HDD is not spinning, it is about 4.5 Watt.

Now I realize that as shown in the video, the BPI is powered the wrong way see https://wiki.banana-pi.org/images/4/45/Banana_pi_BPI-M1_1.jpg https://wiki.banana-pi.org/Quick_Start_Banana_pi_SBC Powering shall be done via the microUSB connector that is between the SATA power connector and the SATA data connector. Or via GPIO pins.

I used this image as base and from there did in-place full-upgrade: It used to lock-up with a kernel crash after 2 - 3 days, kernel 6.6.44 till 6.6.75. I have no HDMI connected anymore, only serial console cable, SD-card, microUSB power, RJ45 and SATA 8T HDD. Now with kernel 6.12.20-current-sunxi uptime already 6 days. I have radically modified partition setup, use Btrfs for rootfs, I do not use Armbian initial repartition scripts, that seems to be the point where your M1 fails. You need serial console cable and post clear text output where it fail. Still then, it might be too complicated to or time consuming fix. You could prepare/create/build a new own image using Armbian build. Or just stick to that older working image. It could be that the GUI drivers like it was in older kernels is dropped after 5.10 kernels or so, that happens to older hardware unfortunately. What is the kernel version where it still does work?

You know one can have multiple DE's installed and select which one to use at login? sudo tasksel kde-desktop lets you add KDE Plasma for every Debian based install. Important note is that RK3588 needs a pretty new mainline kernel otherwise forget KDE. With vendor kernel it should be no issue. So if you want to use KDE Plasma, no new image or install is needed. But maybe you only want to build an image and not use it.

Maybe have a look again: The NanoPi-R6S has 2x 2.5Gb eth and 1x 1Gb eth and soldered eMMC and a openWRT variant pre-installed. Can be ordered with all metal fanless case. I ordered the C variant as I wanted an M.2 M-key for my already Samsung 970plus 500GB NVMe SSD. Idle is about 1.5 Watt with Armbian vendor kernel but it runs various other distros as well with a Armbian rockchip64 kernel. As indicated, I use mine as a generic compact computing box currently, but I can imagin people use the S variant as router as is.

I did this: sed -i 's/buster/bookworm/g' armbian-image-release sed -i 's/21.05.1/25.2.3/g' armbian-image-release But I have motd stuff all muted as all is CLI/remote/ssh/unattended only. It is only for the case that in 1 or 2 years from now I don't get confused by 'buster' again. But I think this file gets orphaned for people doing in-place upgrades (not wiping SD with new image at least. I use it only to see when and how I got the new SBC and architecture/SoC running first time when not knowing much about a platform. For the 5 NanoPi-NEOs, they are all copied/cloned from just the first one I bought and got working and modified so it is a partition structure (Btrfs for root at least) that fits my regeneration-from-backup-NAS script for all Linux clients. After the clone action, the package tooling (and sources.list* contents) determine versions. What matters for me is MACaddress essentially (and some other keys and UUIDs). I only use os-release to see what distro flavor it is. And sometimes 'hostnamectl status' to see what is running.

On my NanoPi-NEOs I have seen this several times/years /etc# grep -d skip buster * armbian-distribution-status:buster=eos;upgrade=bullseye,bookworm,trixie,testing armbian-image-release:DISTRIBUTION_CODENAME=buster mime.types:application/rpki-ghostbusters gbr grep: motd: No such file or directory So I guess those files need some other text

works for me using wget in Linux terminal

I have been using 64-bit x86-64 and aarch64 virtual machines as router since 2016, in combination with a simple managed switch that separates and/or combines VLANs depending on ISP and physical connection (ADSL, 4G, fiber). Currently RPi4 where the router VM is 2 cores and 768MiB and connects to 'LAN' and 'WAN' VLAN/bridges. I can still max download at 350Mbps which is my max fiberspeed. I also have a NanoPi-R6C that can replace the RPi4 eventually, it currently serves as faster clone/backup/development, like routing everything via 4G smartphone for example.

I think you might need to have Secure Boot disabled. It might be enabled by default in newer UEFI firmware.

Yeah what version... You need to be more precise, but I guess you don't have a serial console/debug cable connected so you can show at least yourself what the board is doing. This way, at least I can't help you. Also you can interrupt U-Boot and via commands (see U-Boot help on various websites) check for existence of storage interfaces/devices. It is before the kernel is loaded.

So SPI flash is not all zeros, you have it filled with that U-Boot version. In the log I see mmc0, but I might be that this old U-Boot in SPI flash somehow hides it. I would make sure you boot a mainline U-Boot. You need a serial console cable to check which U-Boot from which device is loaded and used.

I assume 'without success' refers to: all zeros in 'SPI flash chip'. There could be other effects as well. All Armbian Rockchip kernels have eMMC (just '/dev/mmcblk*' essentially) fixed/builtin in the kernel so in vmlinuz, no initrd or overlays needed. I don't know OP5+ HW, but note that you can have 3 bootable storage devices on a Rockchip based SBC where U-Boot can be loaded from. So besides SPI, also eMMC and/or SD-card can contain a U-Boot bootloader (see first 16MiB of those devices). If so, then the question is what version of U-Boot? Besides lacking a mmcblk dev, like is the case for example if I use an old version of EDK2 UEFI on my NanoPi-R6C (RK3588s) on the eMMC(!), It might be that a mainline U-Boot version does not work with vendor kernel. I had that for my Rock3A for example (kernel crash).

If your userspace is also still Bullseye, you have to provide more info or just figure out yourself. I updated my BananaPi-M1 earlier this week, but runs Bookworm. I need to look-up what U-Boot I have installed, but I have a serial console cable permanently connected to another SBC, so in case it does not come online (no IP connection), I look at what the serial console port spits out. That is what you also need to do I guess. Kernel 6.6.75-current-sunxi work fine for me, was unattended upgrade+reboot.

At least the Armbian U-Boot .deb packages and also what is written in the image bootsection between partition table and 1st partition is not capable of reading Btrfs. So If you want Btrfs for root filesystem, you need 2 partitions: a first small one formatted FAT or Ext4 for boot files (kernel, initrd, DTB, overlays) and then 2nd for rootfs Btrfs formatted. I constructed this manually for my old 32-bit NanoPi-NEOs, in the past, but if you do a custom Armbian compile/build selecting Btrfs for rootfs (also with additional Zstd compression) it gets all done out-out-of-the-box. If you want a single partition, build U-Boot yourself, with BTRFS enabled. It are 2 settings you need to set to YES. Then write that binary to the bootsection and it can read boot.scr (and armbianEnv.txt. etc) from that 1 single Btrfs partition. I can lookup some old topics here on the forum, I currently keep a 2 partition scheme as I use various U-Boot blobs (also from Radxa) so an extra FAT partition is a bit more failsafe when all there is a serial console cable. It also is then the same as a UEFI system, that also needs a FAT formatted partition where a bootloader and/or bootmanager is located.

Ran a build, it packs overlays: [🌱] Packaging linux-dtb [ rockchip64 linux-rockchip64-edge ] [🔨] [ 21M] /local/s0/armbuild/rock-3a/build/.tmp/work-efccbebe-0297-4492-8451-549f4047d14e/kernel_dest_install_dir-w5E9G/dtbs [🔨] └── [ 21M] rockchip [🔨] ├── [ 75K] overlay [🔨] │ ├── [1.9K] hinlink-h88k-240x135-lcd.dtbo [🔨] │ ├── [7.2K] README.rockchip-overlays [🔨] │ ├── [ 459] rk3308-b@1.3ghz.dtbo etc. /local/s0/armbuild/rock-3a/build/output/debs# dpkg --contents linux-image-edge-rockchip64_25.05.0-trunk_arm64__6.14.0-S38fe-D0000-P6158-C3a01H3d80-HK01ba-Vc222-B9bbb-R448a.deb | grep "rockchip/overlay" | grep README -rw-r--r-- root/root 7355 2025-03-30 11:34 ./usr/lib/linux-image-6.14.0-edge-rockchip64/rockchip/overlay/README.rockchip-overlays So my local build is fine; seems something wrong in the 'Armbian build cloud infrastucture', I don't know anything about that.

Indeed they are copied or symlinked there from .deb package: linux-dtb-edge-rockchip64 But also that package does not include any overlays. I (re-)installed this linux-dtb-edge-rockchip64 package again now (trunk.313 instead of trunk.311 yesterday) and also that package lacks overlays. E.g. check with: dpkg -L linux-dtb-edge-rockchip64 | grep "rockchip/overlay" So even that there are 2 Armbian packages containing the same set of dtb+dtbo files, none of those 2 edge packages contains overlay files. So it seems something wrong in Armbian build, maybe only packaging, maybe even they are not build/compiled. This is actually a test for my Rock3A (or new/extra RK35xx still not purchased) to see if I can work with mainline kernels instead of vendor (6.1.99). Note that for 'vendor' the overlays are there. 'current' I don't know, I do not use it at the moment.