eselarm

Ultra is not the standard OPi5 nor OPi5Pro, AFAIR it is also RK3588 v.s. RK3588S wich is a major difference w.r.t. PCIE Use a recent kernel/image, see https://armbian.com/boards/orangepi5-ultra And report brand and type of the M.2 NVME SSD. Some people have asked similar question and turned out to be a M.2 SATA SSD

Good that your bpi appears to be stable. My did hang again, no reaction on serial console, no reaction on IP networking. So I enabled the watchdog, uncommented the 'ping 192.168.1.1 line' and made it ping 192.168.1.100 and temporarily added that address to another computer: ip addr add dev br0 192.168.1.100/24 Then removing it: ip addr del dev br0 192.168.1.100/24 and after a minute or so: [ 263.929336] systemd-journald[236]: Received SIGTERM from PID 1071 (watchdog). [ 265.185973] systemd[1]: systemd 257.13-1~deb13u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -BTF -XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE) [ 265.221538] systemd[1]: Detected architecture arm. [ 269.100327] systemd[1]: Failed to fork off sandboxing environment for executing generators: Protocol error [!!!!!!] Failed to start up manager. [ 269.146571] systemd[1]: Freezing execution. This looks like HW watchdog does not work. Same trick on NanoPi-NEO, so also sunxi kernel although 7.0.12-edge-sunxi, it resets. So appears to work although no proof that it is HW reset. I have not checked live dmesg or so, just noticed it went offline and came back later when I also added that .100 IP address again.

If you use and Armbian image with kernel '6.1.115-vendor-rk35xx' (note there are many builds over time, all same name, but you need to look in config-6.1.115-vendor-rk35xx and maybe also consider the gcc compiler version to have RKMPP based method working. I mean the API is there, you need a special ffmpeg (from jellyfin for example to use it) in order to use RKMPP based decoding and encoding in HW. That is just CLI, server use-case, works on RK3568 and RK3588. RK3576 should have the same speed/ASIC blocks as RK3588 AFAIK, but check yourself. It can do 5x realtime speed 1080p50 HEVC to H264. mpv 'uses open and agreed standards' and RKMPP is not. Also Android is completely different. Same is Windows or Apple iOS. Those are implemented by commercial/paid developers. In fact it is worse, ffmpeg open-source developers have concluded already long time ago the Rockchip downstream kernel code was copied and violates licenses. (Rockchip copied code and put their names in it.). So since a few months, ffmpeg developers requested github to remove access and that happened. So following GPL licensing, that 6.1.115 kernel is essentially illegal. How you want to deal with that is up to you. It is like it is. Anyway, 6.1.x downstream is getting old and might contain several unpatched security holes. So over time the 'problem' will solve itself as people won't trust it anymore despite being able to use every HW block in RK35xx. As already said, decoding generally is implemented as part on mainline kernel, you just need matching latest userspace. Encoding is much more complex. If you want that, only Intel/AMD is more or less viable option. Like N100, so in cheap miniPCs, certainly considering high RAM prices, is just a way better option. Plays all HW accelerated in FireFox (and mpv as well). Does also VP9 encoding for example, is a royalty free codec, so you won't see this 2 decades old patents issues for H264 and HEVC. Also note AV1 HW decoding was the first to be available in mainline kernel for RK3588. There is just not much content I think. And HW AV1 encoding is another level of new silicon, is not really an option to do in software.

# cat /etc/NetworkManager/system-connections/br0.nmconnection [connection] id=br0 uuid=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c type=bridge interface-name=br0 zone=trusted [ethernet] cloned-mac-address=my eth0 mac address [ipv4] method=auto [ipv6] addr-gen-mode=default method=ignore # cat /etc/NetworkManager/system-connections/eth0-br0_slave.nmconnection [connection] id=eth0-br0_slave uuid=31645756-5c39-4184-a0c2-337ae09422ec type=ethernet interface-name=eth0 master=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c slave-type=bridge # cat /etc/NetworkManager/system-connections/wlan0-br0_slave.nmconnection [connection] id=wlan0-br0_slave uuid=4ff7f9f2-056e-4836-9bc7-0e77d98a989c type=wifi interface-name=wlan0 master=75d54cd2-cdfe-4621-ab45-0bddf3ab4e6c slave-type=bridge [wifi] band=bg channel=1 mode=ap ssid=mywifissid [wifi-security] key-mgmt=wpa-psk proto=rsn; psk=mypassword template, stripped, optimized, cleaned, untested

I would not give up on the BPiPro just because this networking stack/tool issues. As I indicated, a bridged WiFi AP works fine with NetworkManager. Armbian images are there to get you started very easily, even without Linux know-how. But it still is Linux, open-source, all DIY and no company you can manage to blame (try to find the engineer(s) who designed the SBC ... ). I know the majority of SBC users throws away working older installations and then get stuck with some new pre-installed image. You can instead just dist-upgrade in-place Netplan is from Canonical and there to uniform Ubuntu so NM and systemd-networkd can be used. Debian does not need netplan, there is no dependency on NM nor systemd-networkd. Now look at this: A script from Armbian does netplan yaml that does .netdev/.network files or .nmconnection files. As long as it works, fine. But 3 layers, from math permutation you can know that means many more potential error cases. So you want to discard HW because networking config tooling has become too complex? I forgot to power off the RPi3b+ before night and now in the morning the internet on the smartphone still works (via that AP). A simple reboot via serial console and short flip to 4G but then back to connected to the AP. BUT, the wlan0 again shows as 'failed'. So it seems a timing issue or so or just the status reporting is the issue. Also Android normally simply disconnects on PHY/MAC layer if no public routing ('internet'). That might happen easily after reboots or so or just without various timeouts. Note I have disabled systemd-networkd-wait-online.service else always 3 minutes waiting at reboot. You can also specify how and what to wait for, but needs reading docs. Also note that OS is not vanilla Debian aarch64, but from RPL, there is many changed packages, especially also in the network domain. And RPi3 has USB connected networking, not on the SoC like most other SBC's, this is also an issue I discovered. I see for another RPi3: @/raspi4/latest/etc/NetworkManager/system-connections -rw------- 1 root root 259 Jan 21 16:16 br0.nmconnection -rw------- 1 root root 217 Jan 21 16:16 eth0-br0_slave.nmconnection -rw------- 1 root root 312 Jan 22 10:44 wlan0-br0_slave.nmconnection Is still RPiOS arm64 bookworm, but with some hacks to prevent netplan and cloud-init disturbing things and wasting time, it also works with RPiOS Trixie. Certainly without tricks on standard Debian Trixie as I simply copy those 3 files to and from old AMD fanless computer etc that also has WiFi onboard. You need to make sure you stop and start NM at the proper moments and also make sure no UUID doubles or orphans. Should be fine when new, not yet booted image.

You disable the zram swap, I forgot how, I think look in /etc/default/ambian* files. Else disable or mask the specific .service file.

This is no success, it id wrong implementation, it is AI, from concept/principel it seems OK, but implementation is NOK So I think I stop experimenting and will use NM if bridged WiPi AP is needed, I have several optional working in Debian Trixie and other distro. For wired lines, systemd-networkd with brideges and VLANs work OK. As said already, Debian has netplan optional, so in Armbain Trixie I simply do apt purge --autoremove netplan.io (and install NM via apt install network-manager). Then via nmtui it is easy to setup a bridged WiFi AP, no hostapd needed. By the way, you have several errors w.r.t. your SD-card, might be a sunxi kernel issue, but also you brad SD-card or so.

Problem seems to be that the wlan0 somehow must have a carrier, else it cannot be added to the bridge. A quick hack in a running system, done via serial terminal is: root@raspi7:/etc/systemd/network# systemctl stop systemd-networkd ; systemctl restart hostapd ; systemctl start systemd-networkd Then: root@raspi7:/etc/systemd/network# networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether enslaved configured 3 br0 bridge routable configured 4 wlan0 wlan enslaved configured I did some more testing and also with wlan0 stated as fail, I could browse the internet on my smarthone via the AP. Note that in the meantime, I also simplified the 10-* files a bit, added a MACAddress same as eth0 for br0, so my routers issues same IP address when DHCP, but that is not fundamental to this issue I think, i more how I do it also via NM and how it was automatically in old Linuxes. Google/Gemini suggests to add Before=systemd-networkd.service to hostapd.service, maybe I try, but I find that a dirty hack, it should be already in the OS, although Trixie is not the latest Linux.

I made a comparable setup on a raspberrypi3b+ and I see in the journal: Jul 07 17:37:01 raspi7 systemd-networkd[292]: wlan0: Configuring with /etc/systemd/network/10-wlan0.network. Jul 07 17:37:01 raspi7 systemd-networkd[292]: wlan0: Failed to set master interface: Device does not allow enslaving to a bridge. Operation not supported Jul 07 17:37:01 raspi7 systemd-networkd[292]: wlan0: Failed It worked many years ago when it was buster or bullseye and using ifupdown interfaces network setup. Also ported that to NetworkManager before Bookworm and that works, also in Trixie. This is my first manual setup, as it is Debian Trixie based, I can avoid the use of netplan.io. I remember I have seen this issue somewhere, It might be a newer release systemd issue. But have not searched internet now, will see later why this is.

I had a quick look at the script, but it is too complex for me to see what could be wrong. Also there is netplan layer in between that I am not familiar with anymore. Maybe you can look at what is generated in terms of systemd-networkd files (e.g. in /etc/systemd/network/ ). And also use commands like ip route etc to see the actual state.

As far as my experience is, there is no difference in final result if you do manual 'install' like you did. It runs the usual (user) setup scripts. It is even the same when you start an image as container, done that many times for various platforms. In fact writing SPI-flash is non-automatic, is manual as can be quite invasive. With modern ARM64 SBC like ROCK5B also people might threat it like a PC, with difference that PC comes with a motherboard that has already firmware/bootloader/UEFI/BIOS written by the manufacturer. Although some motherbaords also can use open source, like coreboot I think, but guessing. What to do as further tuning and customization depends on what you want to do with the ROCK5B. There is 1.5 decades between the single core ARMv6 based RaspberryPi1 and the current high-end SBC's that are 100x faster and can be treated like an Intel/AMD PC. I actually have no NVME for x86-64 (is still SATA SSD although also M.2 slot as well), but use my 500GB Samsung 970 EVO+ in the ROCK5B. I use Btrfs and compress-force=zstd for almost all Linux rootfs, so always create an extra swap partition, although a swapfile also works nowadays with special create options. I rather not use the (currently very expensive) RAM for swap when 4-lane PCIE v3 NVME is there. But that is also because my ROCK5B acts as a server, containers and KVM etc and also I use the RAM and NVME for caching a large HDD. So in terms of wear of flash storage, that caching is just way more demanding than what happens on a decade old SD-card only SBC. But NVME/SATA SSD's have perfectly readable stats and many good brands can write more TeraBytes than the specs mention from manufacturer. SD-cards can be very poorly design internally, and have no stats. So you simply don't know when they will break. If the SBC only does some simple things like camera streaming or some sensor's on GPIO pins, it makes sense to keep as much as possible in RAM. So then just keep it like it is. Or even disable journal to non-volatile storage if never any issues and only enable if troubles. One problem I had with zram swap is that on a 256MiB NanoPi-NEO, it failed when media streaming under memory pressure. mp3 or opus or h264 etc don't compress and can still buffer a lot, so the OOM killer started acting. I was not able to change the whole media stuff so stopped zram swap and put swap on normal extra swap partition.

OK I see: # dmesg | grep watchdog [ 0.462093] sunxi-wdt 1c20c90.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0) That would mean study 'bark' or so, forgot most of it. I guess the board should restart if IPv6 LL connection is not there for more than 1 minute or so, but in relation to NAS makes then only sense if I move from NBD to iSCSI or so.

The forum returned 'nginx bad gateway' but I see draft of may message is still there. In the meantime, I did a simple 'apt update && apt full-upgrade && reboot' and now I have: U-Boot SPL 2024.01-armbian-2024.01-S866c-P7738-Hb9d3-Vf23c-Bb703-R448a (Jun 21 2025 - 02:53:13 +0000) Kernel: Linux 6.18.35-current-sunxi I might look into HW watchdog things, no clue if it is there and able to work, but used it successfully for Raspberrypi4 to workaround USB3 lockups/crashes.

Yes, I have similar issues with 7.0.12-edge-sunxi kernel, see serial dump/log below: [ 133.382506] Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2 [ 133.389572] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs sunrpc cp210x binfmt_misc usbserial lima gpu_sched nls_iso8859_1 drm_shmem_help er sun4i_gpadc_iio sunxi_cir axp20x_adc sun4i_ts sunxi_cedrus(C) v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc display_c onnector cpufreq_dt evdev cfg80211 rfkill nfnetlink ip_tables x_tables autofs4 btrfs xor xor_neon libblake2b raid6_pq pinctrl_axp209 axp20x_usb_power industrialio sun4i_ gpadc sunxi phy_generic realtek [ 133.437258] CPU: 1 UID: 0 PID: 184 Comm: kworker/u8:5 Tainted: G C 7.0.12-edge-sunxi #2 VOLUNTARY [ 133.447746] Tainted: [C]=CRAP [ 133.450738] Hardware name: Allwinner sun7i (A20) Family [ 133.455991] Workqueue: pm pm_runtime_work [ 133.460075] PC is at __rpm_callback+0x64/0x10c [ 133.464565] LR is at rpm_callback+0x51/0x58 [ 133.468789] pc : [<c06d2e40>] lr : [<c06d2f39>] psr: 400f00b3 [ 133.475083] sp : f0a5de90 ip : 00000018 fp : c2ef5200 [ 133.480337] r10: c01761ed r9 : 000f4240 r8 : 00000008 [ 133.485590] r7 : 00000000 r6 : 00000000 r5 : c06d0aad r4 : c1e25410 [ 133.492146] r3 : 60000000 r2 : c1e25410 r1 : c1e25410 r0 : c06d0aad [ 133.498704] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA Thumb Segment none [ 133.506135] Control: 50c5387d Table: 43eb406a DAC: 00000051 [ 133.511902] Register r0 information: non-slab/vmalloc memory [ 133.517616] Register r1 information: slab kmalloc-1k start c1e25400 pointer offset 16 size 1024 [ 133.526415] Register r2 information: slab kmalloc-1k start c1e25400 pointer offset 16 size 1024 [ 133.535209] Register r3 information: non-paged memory [ 133.540302] Register r4 information: slab kmalloc-1k start c1e25400 pointer offset 16 size 1024 [ 133.549095] Register r5 information: non-slab/vmalloc memory [ 133.554795] Register r6 information: NULL pointer [ 133.559537] Register r7 information: NULL pointer [ 133.564279] Register r8 information: non-paged memory [ 133.569367] Register r9 information: non-paged memory [ 133.574455] Register r10 information: non-slab/vmalloc memory [ 133.580241] Register r11 information: slab task_struct start c2ef5200 pointer offset 0 size 2624 [ 133.589123] Register r12 information: non-paged memory [ 133.594301] Process kworker/u8:5 (pid: 184, stack limit = 0xe8b1571c) [ 133.600779] Stack: (0xf0a5de90 to 0xf0a5e000) [ 133.605178] de80: 60000000 c1e25410 c06d0aad 0000000a [ 133.613397] dea0: 00000000 00000008 000f4240 c06d2f39 c1e25410 c06d0aad 0000000a c06d3f23 [ 133.621617] dec0: c0ab03bf 00000402 c15b5180 c9306c24 c3790705 c34c3c70 c1813000 bf8e21ad [ 133.629836] dee0: c2ef5200 c1813000 01000000 569e35c7 c34f0c70 c1e254f8 c1e254f8 c1b9de00 [ 133.638054] df00: c1813000 01000000 c1b9de05 c1b72670 c1813000 c06d45a7 c2fb5900 c0141a87 [ 133.646273] df20: c3790000 569e35c7 00000000 c2ef5200 c1813000 c2fb5930 f0a5df50 c2fb5900 [ 133.654492] df40: c1813000 c2fb5930 c1603d80 c1813020 c2ef5200 c181305c c1813000 c0142345 [ 133.662711] df60: f0a5df78 c1603d80 f0a9deb8 c36b8fc0 c2ef5200 c0142245 c2fb5900 c2d35c80 [ 133.670929] df80: f0a9deb8 00000000 00000000 c0149e29 00000001 c36b8fc0 c0149d59 00000000 [ 133.679145] dfa0: 00000000 00000000 00000000 c0100155 00000000 00000000 00000000 00000000 [ 133.687359] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 133.695575] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 133.703775] Call trace: [ 133.703812] __rpm_callback from rpm_callback+0x51/0x58 [ 133.711641] rpm_callback from rpm_suspend+0xab/0x514 [ 133.716756] rpm_suspend from pm_runtime_work+0x3f/0x70 [ 133.722045] pm_runtime_work from process_one_work+0x12f/0x390 [ 133.727947] process_one_work from worker_thread+0x101/0x254 [ 133.733667] worker_thread from kthread+0xd1/0xec [ 133.738431] kthread from ret_from_fork+0x11/0x1c [ 133.743189] Exception stack(0xf0a5dfb0 to 0xf0a5dff8) [ 133.748280] dfa0: 00000000 00000000 00000000 00000000 [ 133.756494] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 133.764705] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 133.771365] Code: f7ff ff7c 4640 f7ef (fd27) f104 [ 133.776186] ---[ end trace 0000000000000000 ]--- [ 133.780834] note: kworker/u8:5[184] exited with irqs disabled [ 154.802648] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 154.808663] rcu: 0-...0: (10 ticks this GP) idle=4c4c/1/0x40000000 softirq=7570/7571 fqs=2625 [ 154.817336] rcu: (detected by 1, t=5252 jiffies, g=14613, q=22 ncpus=2) [ 154.824076] Sending NMI from CPU 1 to CPUs 0: It was 3 weeks ago I did see this while doing some maintenance,upgrades,tests,experiments. Mine is a Bananapi M1, I use sun7i-a20-bananapi.dtb as DTB, and should be same for U-Boot, although I would need to check again what version/build I use. A difference is WiFi and some others, but my guess is there is something wrong/ongoing that is getting worse over time, as also with less newer kernels, it locks up after a few days quite often. This has been the case since december 2024 kernel 6.6.x as far as I see that written in my notes. I noticed that because I have used my Bananapi as NAS (blocklevel NBD). But it were paging issues and never really could find a pattern, always random. This error message is different, but might have same root-cause. Kernel 6.16.x I have run, but it lacked AXP PMU driver for the LiPo battery powering/charging which I use every now and then (is a great UPS like that). 6.18.x had it back again, but also lockups (same paging issue, I have already a kernel log dumping 24/7 to try to figure out what is wrong, but actually have no clue). I also used 6.12.90+deb13.1-armmp, so vanilla Debian kernel, but it has no overlays available and also no AXP PMU module, so that make it less useful. I set it back to 6.12.58-current-sunxi so that at least it runs reliably for a few days and I can use it ad-hoc as a serial console terminal for a Raspberrypi4 that also used to crash randomly due to USB3 stack issues and also for debugging and testing rather complex networking issues. I am using custom partition layout, the whole thing also runs as 32-bit UEFI KVM as well as systemd-nspawn container (same cloned MAC address so I un-power the real Bananapi then). The setup uses custom extlinux and standard grub-efi. I could easily test 7.0.x or later in a KVM, but assume it will run fine. It is really something about a combination of A20, platform HW, U-Boot, DeviceTree I think. It is a pity as this SBC is about the most useful I have due to its onboard SATA and LiPo battery management, although not 64-bit.

maybe first post the output of uname -a on the raspberrypi3B+

Armbian is I think the easiest way to get Linux running on many many SBC's, but it is already pre-installed. So just 1 OS 1 boot method. If you want more , it is all DIY. Same as if you buy a a Windows laptop and want Linux on it essentially. Or just a DIY build PC where you put Linux on. You will need to understand disks, partitions, BIOS settings etc. But as you say Armbian is a good start as it is Linux so all can be done. An Armbian image for the RK35xx based SBC also contains the proper U-Boot, it is just that that U-Boot uses boot.scr as primary boot method. So if you remove or rename that file, it tries other methods, like extlinux and also as you need, EFI. But it needs to find a partition of type 0xEF00 and just FAT formatted with /EFI/boot/bootaa64.efi on it (or maybe Ext4 also works, at least it does not for computers with UEFI BIOS, those can only read FAT). What you can do to test is to move/delete/rename boot.scr in the rootfs of the Armbian install on the SD-card and then have/put a Armbian UEFI for Aarch64 on NVME/SSD/USB-stick. Or just hide/delete all partitions on the SD-card, then it is essentially only a storage place for U-Boot, same as EEPROM/SPI-NOR-flash on SBC's that have such a chip. Of course you can also go straight to Guix installing yourself, from iso9660 tha tyou put on CD-ROM or USB-stick. But advice is to have a serial console cable connected as U-Boot normally does not initialize HDMI, so don't come here and report 'black screen it does not work'.

raspbian is old 32-bit ARMv6, or maybe you use wrong naming. I see orangepi pc2 is also 1GB RAM and 4x Cortex-A53. So that is the same as RPi3B+. Armbian should be 64-bit on the orangepi pc2 and if that runs fine for you with HA, then it should also run fine the same way on RPi3B+. Armbian has no 32-bit support for raspberries, so maybe have a look if there is a ready-made image. The root filesystem on the orangepi pc2 you have currently should run almost unmodified on a RPi3B+. The issue is that raspberries boot filesystem is proprietary, but if you know or get to know how it works, you could get it to run.

I thought you made a typo with HACS but it seems you mean this https://www.hacs.xyz/docs/use/ I guess, look there Armbian is not HA support or so. Or else ask som eAI tool for hints (and make sure you understand how to avoid hallucinations of such AI tooling).

OK, I did not look into further details, I don't have any of this HW. I only have same experience 10 years ago, 4G module works in USB adapter, did not get it to work in mPCIE slot. I am not sure if a DeviceTree patch/change can fix it, don't know enough of that description principles. As indicated, SeeedStudio can read this, it is their HW, maybe they should fix it for you.

My thinking is that with a standard example tool from libgpiod (gpioset) it should be possible to toggle a GPIO line. I see 'P05' that seems a pad number of the RK3576. I remember I had to dig deep in internet fora for something similar for BananaPi M1 to see what to put in armbianEnv.txt. Or NanoPi-NEO. The later I use with those example gpioset to toggle a GPIO to switch some own electronics on/off. You could also use lgpio (rpigpio successor or any other that can toggle pin states). Note that formally, you need to threat a GPIO line like a file, claim, open, close etc. After that state is undefined, but most SBC kernels keep the state, but formally undefined. See many many discussions on wiringpi etc. W.r.t. this combPHY: the RK3576/RK3588: those can act as several SerDes, it is sort of multiplexed, so cannot be all at the same time. But you need to look in schematics. I use the SATA<> PCIE2x1 swap (on E-key slot on ROCK5B and ROCK3A) but it very much depends on what firmware/bootloader and DTB(O) and kernel. For the ROCK3A for example, I still don't have it working according to I wish with mainline based U-Boot+kernel. Only vendor 6.1 and legacy U-Boot. I see on the SeeedStudio page: preloaded with Armbian, so this topics is a sort of test-case IMO: is that claim with mainline based or vendor/legacy Rockchip; I guess the latter, so maybe list versions of various system software. 'Forky' is not released, so a moving target or rolling release, others don't know what versions you use so not possible to reproduce the issue(s).

A quick diff scan: 'kompare config-6.18.34+rpt-rpi-v8 config-6.18.35-current-bcm2711' about 700 differences, no clue if this is reason for no detection. I made Debian Sid running, currently kernel 7.0.13+deb14-arm64, cam -l finds no CSI cameras, simple USBcam works fine. But is upstream_kernel=1 and there is no overlays for CSI cameras. Then copied 6.18.34+rpt-rpi-v8 kernel+initrd+dtb(o)+firmware from a running latest RPi Trixie (so 64-bit Debian based, not Raspbian re-compiled for armv6) and commented config.txt line upstream_kernel=1 and also set console to ttyS0, not ttyS1 otherwise hang at serial console. So with waveshareH NoIR (=ov5647 sensor) attached: 'cam -c 1 -C1 --file=raspicam.jpg' run as root works, however the picture is just black and white vertical lines. Then swap 6.18.34+rpt-rpi-v8 kernel+initrd+dtb(o) with the ones from 6.18.35-current-bcm2711: cam -l does not see a camera although ov5647 overlay is loaded If I use a faulty configuration, like upstream_kernel=1 the ov5647 overlay is loaded, but fails to initilize due to some i2c-csi-dsi mismatch. So it seems a typical vendor/downstream works, but upstream not. At least for upstream, the camera/sensor needs to be created and in addition, userspace might need changes. Might not only be in libcamera/rpicam, but there are potentially 10s or 100s or more changed debian packages, the most obvious 1 is NetworkManager, see RPi forum.

This is not NVME, but SATA. No surprise it does not work. It might be that the M.2 slot of the OPi5pro is such that with an overlay, you could map SATA signals to that slot and then it should work. Look in rockchip overlays folder for any .dtbo file with name like *rk3588*sata* But you should check HW circuit diagram maybe first, might also be that this is only for the normal OPi5 Maybe search a bit, I found Is old topic, but the principles are still the same.

ubuntu nor gnome is not relevant what matters is u-boot and kernel (and powersupply and type of nvme ssd ) u-boot logs can be seen via serial console cable

What is your plan with that camera? My latest try with raspbian (armv6) trixie based failed w.r.t. V4L2. So that is with start.elf, not start_x.elf. The latter works fine on bookworm based raspbian for camara v1. Camera v3 never worked with legacy firmware mode (start_x=1), so needs libcamera. For easy handling, the latest RPL variant of libcamera named rpicam should work, but then you'll be essentially back to RaspberryPiOS. If you have standard Debian Trixie based, all that modified libcamera is not there and more important, you will have other firmware files (bootcode.bin start.elf fixup.dat). Armbian takes the version from Ubuntu AFAIK, Debian is yet another version as is the latest from RaspberryPiOS (64-bit patched Debian or 32-bit patched and re-compiled Raspbian). The package name is raspi-frmware, check which versions there are with sudo apt list -a raspi-frmware and in addition, the 3 files themselves, I did timestamp or suffix them with sha256sum in the past on order to keep track of the various ones delivered for various OSses and images. I assume the Armbian kernel is compiled from same RPi kernel tree as RaspberryPiOS, so overlays for the v3 camera should be there and functionally the same. I currently have 1 camera v1 base RPI3B+ running, still bookworm, but I might boot it with Debian Trixie/Sid and see what mainline libcamera does. Probably then Armbian bcm2711 edge kernel, at least something that provides overlays as Debian kernels have almost none, at least not for camera sensors.

I see no clear error, only something with hdmi-audio-codec, but that is somehow expected AFAIK with mainline based rockchip64 kernel. I think Xfce is X11 and others default to wayland. You can try KDE in X11. 4K is not fully mainlined AFAIK, but you need to check yourself. You can try an edge kernel, is 7.1.x based, maybe it fixes things. I have seen many such issues (RK3588 SoC) in the past, but thing are remarkably fine with 'latest Linux' (KDE6 1080p60, don't have a 4K monitor/TV).