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.