rm_

I have to say the current Trixie image with 6.18.43 works terribly for me. I do not have serial so it is hard to know why. It does not boot 80% of the time. Flashes black screen briefly on HDMI, then goes to "No signal" indefinitely. During all that time, the green light blinks on the board, and Num Lock can be toggled on the keyboard, so the kernel is loaded and alive. But once it sat there for a while, and then suddenly finished booting. I checked dmesg, and there was a huge gap in time between messages, like 13s, then nothing, then a bunch of all the following messages starting at 200s. And yes, when it even boots, that's also always taking a while. Earlier Trixie build with 6.18.30 boots flawlessly each time, and much much quicker. Indeed, if you ask me not having USB boot on R2S is basically not being able to use it at all, if they don't like USB boot suddenly, then should have soldered the damn $0.03 SD card slot onto that board, or included that magic unobtanium proprietary SD adapter with each order.

Heh, speaking of which, is there no thermal throttling on CPU? Earlier I was trying to set it up as a seedbox, running qBittorrent. Newer versions have a setting to do multi-threaded checksum verification on torrents. Making that use all 8 cores provided nice ~550 MB/speeds, but it did heat up the CPU to 95C or even a bit more! Stopped it all and installed a fan (was just a heatsink before), now it can handle that at reasonable temps.

But they still don't have any 7.0+ for evaluation, any idea when? Thanks

I remember reading somewhere that the top slot doesn't support booting from NVMe. If it's non-boot then it shouldn't matter.

For microSD card slot to even work at all, it is listed as a change that landed only in 7.2. https://www.phoronix.com/news/SpacemiT-K1-K3-Linux-7.2 This is why you get root filesystem UUID not found with 7.0-7.1

Wait for a few hours and see if it appears. My other theory, is that I removed the BCMHD DKMS driver and now the wifi is in a wrong state and hassling the CPU.

It is not that one. The 2.0 load was just cosmetic, the CPU was actually idle. But with this one it is actually doing something, which is also increasing heat (if no fan). With the expanded core list, you can see the CPU5 and CPU7 have "system" load of 49% and 36%. On a fully idle system. Interrupts file attached. It seems pretty normal to me. interrupts

And the CPU load bug is still not fixed even in 6.18, amazing. After the system has been up for a while, these crop up in "top", consuming quite a bit of CPU for no discernible reason. The system is otherwise idle and there's nothing running. I stopped qbittorrent and samba, this strange load does not disappear. And it seems to increase over time, a bit after the screenshot, around 30-60% now.

armbianmonitor picks up the wrong temperature to show as "Tcpu". 19:40:09 1600/1600 MHz 0.63 12% 0% 12% 0% 0% 0% 34.9 °C 0/1 19:40:14 1600/1600 MHz 0.66 12% 0% 12% 0% 0% 0% 34.9 °C 0/1 19:40:19 614/ 614 MHz 0.60 5% 0% 4% 0% 0% 0% 34.9 °C 0/1 19:40:24 614/ 614 MHz 0.56 0% 0% 0% 0% 0% 0% 34.9 °C 0/1 19:40:29 614/ 614 MHz 0.51 0% 0% 0% 0% 0% 0% 34.9 °C 0/1 19:40:34 614/ 614 MHz 0.55 1% 0% 0% 0% 0% 0% 34.9 °C 0/1 19:40:39 1000/1000 MHz 0.51 3% 1% 1% 0% 0% 0% 34.9 °C 0/1 19:40:44 614/ 614 MHz 0.47 0% 0% 0% 0% 0% 0% 34.9 °C 0/1 Time CPU_cl0/CPU_cl1 load %cpu %sys %usr %nice %io %irq Tcpu C.St. 19:40:49 1600/1600 MHz 0.51 12% 3% 8% 0% 0% 0% 34.9 °C 0/1 19:40:54 1600/1600 MHz 0.55 15% 4% 10% 0% 0% 0% 34.9 °C 0/1 19:41:00 1600/1600 MHz 0.58 15% 4% 10% 0% 0% 0% 34.9 °C 0/1 19:41:05 1600/1600 MHz 0.70 15% 4% 10% 0% 0% 0% 34.9 °C 0/1^C Meanwhile in 'sensors': cluster1_thermal-virtual-0 Adapter: Virtual device temp1: +45.0°C nvme-pci-10100 Adapter: PCI adapter Composite: +34.9°C (low = -40.1°C, high = +119.8°C) (crit = +129.8°C) Sensor 1: +42.9°C (low = -40.1°C, high = +139.8°C) Sensor 2: +34.9°C (low = -40.1°C, high = +119.8°C) cluster0_thermal-virtual-0 Adapter: Virtual device temp1: +45.0°C So it shows the NVMe SSD temperature instead.

Tried "Armbian_22.08.0-trunk_Nezha_sid_current_5.19.0_xfce_desktop.img.xz", the result there is much better, 49 MB/sec. But the WiFi onboard of LicheeRV Dock is not detected.

balbes150, There is something wrong with performance. I am trying "Armbian_23.09_Nezha_sid_current_6.1.0_xfce_desktop.img.xz" Doing my simplest performance test: dd if=/dev/zero bs=1M count=256 | md5sum The result is 21 MB/sec. Moving windows in Xfce is really sluggish, even after disabling compositor, leaves trail on screen and lags behind mouse movement. Compared to "licheerv-debian-clean-hdmi.zst" from https://linux-sunxi.org/Sipeed_Lichee_RV#Pre-made_images (last in the list). Using kernel 5.18. The same benchmark returns 51 MB/sec. Moving windows is very responsive.