eselarm

When I got my ROCK3A around 2024-12-01 I thought it was a good idea to use a newest Linux userspace so I started with Armbian Ubuntu minimal image. Just getting to know the board HW and only SD-card and serial console and RJ45 that was fine, but soon the problems started. I managed to install NetworkManager and disable networkd, so I could copy a rather complex set of NM files from my other SBC, NanoPi-R6C that is using bridges VLANs and libvirt KVM. Same as I did earlier copy that same *.nmconnection files from RaspberryPi4 (PiOS bullseye/bookworm) . And just changing a cloned-mac address entry essentially in 1 .nmconnection file initially so my router assigns the correct IP address (just initial setting), changed that later. Long story short, it turns out that you need netplan.io and that generates .nmconnection files in /etc/NetworkManager/system-connections/, at least that was my conclusion after doing tricks with apt, maybe it is different, I did not want to waste time on it anymore. Same .nmconnection files (same content) are somewhere in /var or so, I forgot where and those seem to be generated from netplan yaml files. I once constructed yaml files to get 64-bit Ubuntu server image running on RPi4 when RPL only had 32-bit ARMv6 raspbian, but already then I thought never again that netplan stuff. I already removed all snapd stuff myself. So after wasting way too much time I just created a clone image on an SD-card from a Btrfs snapshot of my running NanoPi-R6C, copied some U-Boot and kernel and DTB files then done. Could start even VMs on dedicated VLANs etc. That by the way is also an issue with Ubuntu, they keep certain files needed for running KVM different from Bookworm, so VMs did not start, I needed to look at Ubuntu fora to figure out what the issue was. I forgot what as I wiped it all. So my opinion is more or less that Canonical has some vendor lock-ins here and there and/or 'cookies' to keep you stay with them (Ubuntu). Not internet-browser cookies, but goodies, like adding BSD code to Linux (ZFS). As the world of SBCs is almost exclusively about pre-installed images with most people not able to boot an iso CD-ROM and install Linux themselves, it is easy getting into peoples homes. For me, netplan is like hidden malware as I am unable to just install NetworkManager without also getting netplan and then needing to know/learn 3 network config scripting things. Opensuse Tumbleweed also has its own network managing tool (wicked), but at least that can be ignored if you want NetworkManager (dedicated switch in YaST). Same for Debian although manual apt packages and services actions. And then there is nmtui tool that works via serial console, so for me a key feature to configure networking initially in a good interactive way. It is much easier than reading yaml docs or nmcli command options docs. So lesson learned is that I avoid Armbian Ubuntu, also Armbian Bookworm minimal. Only if downloadable Armbian Bookworm images where NM is default I would maybe use, else just clone 1 of my own installations. For own image generation with Armbian build, there is option to use NM, so I noted that somewhere. Pity is that recommended/supported build host environment is Ubuntu. I did most builds on Armbian Bookworm lately, works fine. But last time I started it on Trixie it failed. Will try again sometime soon.

removed

What U-Boot version is used for eMMC resp. SD-card?

Which version or image is that ? From here ? https://joshua-riek.github.io/ubuntu-rockchip-download/boards/rock-5b-plus.html 5.10 kernel or 6.1 kernel? As already indicated, 'images' usually do have a too big scope for identifying the core issue for flaky boot or crashes etc. Also the Armbian '25.5.1' and '25.2.2' are just a text in some file. For my installations that have been always in-place upgraded, they are wrong anyway. Stating buster when I just did reboot into upgraded trixie for example (NanoPi-NEO). W.r.t. PCI-E, and other specific Rockchip HW, 5.10 (legacy) likely has best support. At least for my ROCK3A, I then have RPi camera V1 support (not tested but required overlays are missing in 6.1). Also w.r.t. the earlier mentioned PCI-E NVME+SATA issue, I got it working by merging the Radxa 5.10 ('latest') kernel + Radxa U-Boot '2017' with some Noble userspace from around December 2024. Now Bookworm by the way as I don't want netplan.io. In a running system (NVME working), you could run 'sudo lspci -vv' and look at Capabilities. When non-working NVME, so boot from SD-card and maybe SPI empty or disabled so only the U-Boot from the SD-card is used, it also might give hints. At least I see that SSD can do 8GT/s 4-lane, while RK3588s (NanoPi-R6C) then has to use 5GT/s 1-lane. It is 6.16.1-edge kernel with EDK2-UEFI v1.1 in eMMC. I don't understand all items, but at least some, w.r.t. power-save (ASPM) among those.

armbianEnv.txt sets parameters for the U-Boot bootloader. In theory you can also manually type it all via serial console at U-Boot prompt. Separating boot and rootfs is independent of that. If you use Ext4 for bootfs, you can make hardlinks (or symlinks). That is also what is done by kernel install script if /boot is on Ext4, else copies are done (when FAT).

I have seen this many times on my ROCK3A and had to do with how the various 'PCI-E I/O' is operated. Some are multi-PHY SERDES, so can act also as SATA or USB3 or Mii. It very much matters which U-Boot and also overlays, which are kernel dependent. I now got 2-lane PCI-E for a Samsung 970 EVO 500MB (M-Key slot) and SATA3 (E-Key slot) working simultaneously. Is a Radxa U-Boot in SPI and vendor 6.1.115 kernel, else it won't work. For the RK3588 on my ROCK5B it works more flexible w.r.t. bootloader and kernel, 3 sets work, so also latest mainline generic distro Linux. The ROCK5Bplus has 2x M-2 M-key, so that is different from a ROCK5B. I am not sure how lanes are routed, but did once check a similar issue RK35xx board and there the bifurcation seemed to be the problem. There are options I think for lspci where you can see how many lanes and that should also be in kernel log. Might need loglevel=7 to see it. It might also be that the Crucial P310 just won't work reliably with the ROCK5Bplus, we have seen something this similar before for an other NVM-E + RK3588 SBC combinations (I think it was OPi5+ and same SSD as I have). Other NVM-E brand worked without issues.

That is basically what I have been doing. I reconstructed image/partitions to have bootfs and rootfs separated. Typically format bootfs as simple FAT where you can fix things even on Windows computers maybe when SD-cards. For new fast SBCs I just have many partitions on NVMe where various Linux distros rootfs are and just copy or rename armbianEnv.txt which is then essentially only a UUID of a rootfs. When I know the SBC well enough, it is more the kernel only that matters, so i made a extlinux.conf generator so I can select a kernel via U-Boot serial console. I don't see what A+B brings me as I use Btrfs for rootfs and use snapper to make 'last-known-good' snapshots and also transfer those to NAS or so. If you want totally unattended, then A+B is an option, look at Android as well I would say. But more towards PC like systems, one can put efi bootloader (efi-grub) on the bootFAT, that allows you to select last-known-good more or less if you deploy snapshots. I usually do update in-place, so more like rolling release, but you can also do updates on a new read-write snapshot and fallback if it would fail to boot, see https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html for example how that works. U-Boot also has options I think to get to last-known-good automatically, but I don't know how that would work. For my stuff at home, it is good enough that I can quickly go back to older snapshot and that works for more than a decade on my PCs, so I do the same on SBCs/embedded, as long as they have a serial console cable (or HDMI,keyboard). For the NanoPi-NEO I also had Btrfs capable U-Boot, so then U-Boot can directly boot a certain rootfs partition, but it is not really default, so I keep an extra bootFAT.

You need an overlay for that camera and 6.1.115-vendor-rk35xx does not have that AFAIR, older legacy 5.10 has it AFAIR. Look for something called RPi camera v1 or that sensor name.

The audio codec issue

So essentially it is about adding/fixing analog audio (3.5mm plug) es83xx in mainline kernel. I am maybe lucky that there is another analog chip in Radxa ROCK5B, but I have also noticed strange (too high too low) volume levels initially, but cannot reproduce anymore as 1 of the distros is Opensuse Tumbleweed and the specific snapshot version is already deleted. It worked fine a month ago (Opensuse Tumbleweed on top of EDK2-UEFI v1.1 in SPI-flash ), but runs Armbian Trixie/Testing now as server, don't know about audio. I use pulseaudio via network normally, but that is broken? in Debian/Ubuntu for 3 years or so as pipewire is default and pipewire-pulse is not native pulseaudio. But I haven't looked into it the last 2 years or so. I had it working in bullseye and upgraded to bookworm needed removing all pipewire stuff to keep it working. New bookworm/Armbian I never got it working. In the end, it is Xunlong I guess selling the HW and not delivering mainline kernel features. Some cheap N100 boards use a well supported USB audio chip, RPi5 removed 3.5mm audio completely, the workaround is to buy a cheap USB audio dongle. So see for yourself how you fulfill your audio requirements. When I bought my ROCK5B, the OPI5plus was about 25 euros cheaper, but it is the onboard power supply circuit and SATA options that made me buy from Radxa and also that the ROCK5B is used by Collabora. It is long time (decade) ago I did some (local) changes to kernel sources, that was torwalds or mainline tree, for Armbian, look in latest build docs options. It is something with kernel-config, you can then pause things and change sources. But better to see if you can manage to fix directly on mainline kernel git.

My experience is that the edge kernel is stable enough, but if you act like a disk-jockey (playing with disks or SD-cards/images nowadays) you destroy your success potentially every time you try some new image. Instead, pick a distro Debian or Ubuntu when Armbian, and make backups and/or do snapshots of what worked and then install packages variants. You can have vendor, current, edge kernels installed at the same time. A lot faster build maybe because the kernel is already build by some person or some computer before, so you get it fetched from a cache. I have added the beta repo in my sources so I can select between various kernels (and U-Boot variants). You need a bootmanager though, so own extlinux.conf script or wipe standard boot.* files and make sure EFI works, with GRUB or so. The latter works fine if you don't need overlays etc, so more use the SBC as PC then as embedded board to control things via GPIO pins or so. You can also re-install a specific kernel every time, but that does not work when the one you wanted to run does not start the board or crashes it. The OPi5plus I would consider as a PC, I do that for similar boards like ROCK5B and NanoPi-R6C at least. I select kernel via GRUB and have a permanent serial console cable connected, so it also works without HDMI connected. It is mainly the choice between vendor and mainline, that is the state of ARM64 nowadays. Some new boards like RPi5 cannot run mainline yet, so then there is little need to have a bootmanager, then you need the disk-jockey methods.

What does: ffmpeg -codecs | grep hevc show? Even if it seems to support rkmpp, you can guess that it is broken. So install/get a dedicated external encoder. 2 people in this topic tread show working options. I can't help you any more, you need to do your homework so to say.

Armbian is a stable OS, but we don't know about what SD-card, power-supply etc you use with your Cubitruck and/or NanoPi Neo+2 The decompression error can simply mean corrupt file due to something wrong with HW. Or something could have gone wrong during download of the files that you or the system decompress. Also note you use a kernel from beta repo (25.11.0-trunk.41). I you want better control, create/build an image formatted as Btrfs, not Ext4. Then you can check where it went wrong. I have several NanoPi-NEOs, all use Btrfs. 2 run 24/7, the others not all the time and usually just get sudden power cut, but they start fine next time. I do in-place upgrade them since years. If something would go wrong, typically as the error you show, I go back to a previous Btrfs snapshot or/and backup from NAS. That is simply what you could do / have done. Maybe something went wrong with that sunxi64 kernel build on the Armbian infrastructure side, that can happen every now and then as it is beta. So Also then, protect your devices again such issues. Also please don't post kernel upgrade errors in a topic about LiPo controller chip. OK for now, but annoying

It is almost 2 years old and no info about which kernel. For you, please indicate which ffmpeg you use. You should have done that already in your first post.

Upgrade to Trixie went fine, but pressing the user-button has no effect. I won't look into it further now. I could try with ROCK5B, has a dedicated power button, but also needs to stay active 24/7 as server actually.

I think I mis-interpreted the sentence with 'the computer'; I did not relate that to OPi5 (but 'normal' PC). Re-reading again, indeed the OPi5 is meant. Then the power is there, the question is then, how the RK3588S and surrounding hardware will handle things. I don't know exactly anymore what all sleep states for traditional PCs comprehend. I know what can be achieved in mobile platforms (very low power), but that also includes switching off parts of DRAM that don't contain needed data, and many more like a tiny Cortex-M0 or so somewhere that is always on. The question is also, how much power is saved? For a LiPo battery in a smartphone this is quite different, so lots of extra system design is done in HW (SOC, PMIC). RK3588 should support it I think, but I am not sure if all the various SBCs can use it, because certain HW lines etc might not be there. At least Broadcom/RPi platforms cannot do anything like that.

I have used/tested KDE-neon a while ago December 2024 I see from rootfs backup, that was on a ROCK3A and to enjoy KDE6. Maybe now if you want KDE6, Trixie has it, so as base Armbian (Debian) then upgrade and/or install KDE plasma (sudo tasksel to select and install). I have it on my ROCK5B, at least with edge kernel it works all as expected, compared with KDE6 on Opensuse Tumbleweed and Debian Trixie on N100 miniPC. In-place upgrade went fine, although the whole user environment from KDE5 is gone and you start from scratch new template KDE6 when upgrade from Bookworm->Trixie. If you want latest KDE, then Neon is now already newer than the 6.3 in Trixie AFAIR, but it seems to me that integration issues can be expected. I see Ubuntu Noble (Kubuntu) has KDE5 still.

This is great, I have done some tests with my NanoPi-R6C a year ago. I have not noted what kernel etc, it also has no dedicated power-button (but a 'user-button') so I think I tried (as root) systemctl suspend and logging via serial console cable. Also looked at wake-on-LAN. CPU is the same as OrangePi5 and your logs I recognize going into suspend, but then it stayed frozen. Maybe if I re-purpose the user-button and push that it will resume. Such a button can be easily connected to a pin on the PMIC or SoC. At least 1 of the RJ45 ports supports wake-on-LAN, I could also set in NetworkManager, but it gets stuck in PCI-E somewhere or on the SoC I think, can be very complex, I don't know. For keyboard that is external to the product (the ARM SBC), USB connected I assume, you need to keep the USB power (5V) alive. Also some extra hardware AFAIK (not the SoC) that detects activity on USB keyboard. Can be very simple, but I think it is all not there for SBCs. There is no keyboard controller chip like in traditional PCs. So I will maybe sometime look in schematics and see what would be possible. So far I only focused on power architecture in general, whether USB-C PD works or not, etc. My NanoPi-R6C is 1.5 Watt when idle and vendor kernel, measured with a USB power meter. I will try to reproduce your power-button suspend-resume sequence first and then also measure power. I use EDK2-UEFI v1.1 at the moment, set to mainline and 6.16-rc3 kernel. Is Armbian Bookworm, will upgrade to Trixie first and then see.

I don't know, but what you describe is that OP1 is essentially able to run from RAM (network I/O mainly) so not so much storage I/O which then lowers the change of corruption. For OP2, is quite heavy disk I/O it seems, also torrents writing is tricky for some filesystems. If you want to know more why and how w.r.t. corruption, use Btrfs instead of Ext4. It still can be difficult if HW caches do the wrong thing, but you can make metadata duplicate and also play with commit time. I have a Pi3B running from SD-card and 4T 3.5i HDD via USB attached. It runs Debian Testing (Trixie now) , FAT bootfs and Btrfs rootfs with hourly snapper and also manual extra snapshots if I do upgrades. Also HDD is Btrfs formatted, 'dup' profile for metadata 'single' profile for data. I gets hard power cut every day at least once as solar powered. I do not do any UPS like noticing, also the power loss might be during a btrfs send|receive transfer, that will then fail, but in my script I delete read-write snapshots first as they should be read-only (so were correctly finished). No data loss or corruption during years. I just have a very simple guess about the amount of sunlight, which might be almost zero for days in winter. On a Pi2B that seems to have damaged GPIO pin 4 and was using a bad brand SD-card, I could quite perfectly see when corruption started, which files you see when you do scrub. It was a logfile and some other file that were recently written, but unimportant, so I could still do a btrfs send of a snapshot of the rootfs to my local laptop new SD-card. I know how to create bootfs for Raspberries. For my NanoPi-NEOs running Armbian I changed rootfs Ext4 into bootfs Ext4 + rootfs Btrfs. You can also use Armbian build to generate that off-the-shelf, I would now use FAT for bootfs as that matches how UEFI computers are organized. You also need extra write of U-Boot, that is not needed for RPi or UEFI. An Ext4 filesystem can be turned into Btrfs in-place with tool btrfs-convert. If it is a rootfilesystem where the OS runs from, you still need to create an extra bootfs though and so also change fstab and also as a consequence the partition table and organisation.

sudo apt-mark hold linux-image-vendor-rk35xx sudo apt-mark hold linux-dtb-vendor-rk35xx

I never used Ext4 directly on a whole block device. Linux in general assumes partitions. Advice is to use partitions. So create one first wit fdisk.

mmcblk1boot0 mmcblk1boot0 are for booting via other boot methods, not used for U-Boot in Linux/Armbian. Don't use them I would say, otherwisie the ROM in the BPI might leave you with a bricked board. You can make a partition on mmcblk1, format it and mount it. Same as with other disks.

lsblk should show you 2 mmcblk devices; 1 is SD-card, the other is on-board eMMC. Which is which number can vary depending on what kernel and DTB. If you only see 1, you should change operating system maybe.

OK so it is Armbian. You can use KVM with the 6.1.115-vendor kernel, but you must set fixed allocation in the VM which CPU cores to use. You can chose 0 to 7, 0-3 are Cortex-A55, 4-7 are Cortex-A76. Read the post(s) I linked to earlier, I and others explain it there (even 2 methods). Use virt-manager GUI ane enable .xml editing. then change that line with the cpus, I my case I use 2 cores. You van also do it with virsh CLI tool, but you need to read through the options then.

gfs2-utils But it looks like you want to share storage. You do not need a GFS2 system for that, but a regular Linux filesystem and a NFS server or SMB server for sharing over the network. Most people will use Ext4 or Btrfs or XFS in Linux.