eselarm

Small update: As expected, 4+ VLANs work when lan1 is used on my NanoPi-R6C (and with 6.12.6 I had running/installed 3 weeks ago). I basically can work with the limitation on the wan port as for normal planned use-case, I do not need more than 3 VLANs, but any test/trial/experiment is impossible then (I have 9 or more VLANs around in my managed switches). I copied the NM config files to my Rock3A, there is is no problem (but other U-Boot, kernel 6.12.6-edge-rockchip64, Noble instead of Bookworm). I do not understand various details of the patch, for example why is something in the realtek driver needed and not just the STM based MAC driver. I need better understanding first, otherwise I think this is above my skills. It might also be that the Gbit port silicon in the RK3568 is newer than the one in RK3588(S).

I don't know what RK3588S board it is, but you better do it the other way around; I have a NanoPi-R6C and Rock3A, they booth do great in terms of generic KDE6 Desktop with their respective KDE Neon images. GNOME I don't know, but I also guess look at the downloadable images. You need latest MESA and an some other thing, they aren't in vanilla Bookworm, also maybe not in vanilla Noble. That is why the dedicated images are there one can conclude. Also latest/rolling openSUSE Tumbleweed KDE6 Wayland with Armbian 6.12.6*rk3588 works fine. X11 does not work AFAIK. So use the GUI/Desktop images as base, then swap/add kernels. I have 2 or more installed and also manually copied. It takes time to get it a bit flexible (choice at boot time via serial console) but it also depends on what storage/boot devices there are. I only connected the boards to a BENQ 1080p60 LED monitor, via some 2-splitter HDMI-switch (Techhole). 1 side of that splitter is connected to N100 box and I push the switch button when I power on the Rockchip SBC. My Rockchips SoC's work slightly better than RPi3/4 in my experience, that has been a frustrating exercise every now and then (3 years or so) as they cause 1 or the other HDMI monitor not want to detect the Pi. 6.12.6*rk3588 on NanoPi-R6C works great with KDE6 Wayland, i think/assume later *rockchip64 includes all from *3588 as well, maybe just a rename, I have not checked. As long as the SoC is rk35xx it should work is what I would expect. What all does not work is various video codecs, but a rk3588 can decode most in software, same as BCM2712/RPi5 has to do. An as indicated, you might be unlucky with your HDMI monitor, some say only 4K works, but I don't have a 4K monitor.

I have copied the kernel+DTB and regenerated initrd and uInitrd on my Armbian NanoPi-R6C rootfs, set those as boot instead of 6.12.6-current-rockchip-rk3588 Reboot works, but still the limit of 4. And also no network connection as I use bridges and also wan (GMAC 1G) itself counts as VLAN 0 But if I do nmcli con down <a currently unused test VLAN>, there is room for VLAN 0 (done all via serial console), then base LAN connection is there. I have lan1 (realtek 2.5G) unused, workaround would be to use that for the single RJ45 cable connected to the NanoPi-R6C, but plan was/is to use that for other point-to-point link. So I think I will need a closer look and see what could be wrong.

which image did you write to the SD-card ?

Various (newer) Armbian OS images do not have a separate boot partition (anymore). So there is then only 1 partition where also the DTB files are and it is Ext4 formatted, which Windows cannot read. So you need a Linux computer to do DTB file copy. You might encounter another problem, as usually a DTB file is paired with a matching kernel/version, but I do not know your files/version/images, also have no Amlogic box.

The SoC has an ADC AFAIR, but it is used for 'Recovery Key' AFAIR. Look in Radxa PCB schematics to be sure.

I see from: http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_5_Plus#Start_the_Orange_Pi_development_board what you mention: No PD, only 5V. That means that you cannot use a USB-C PD measurement device that shows actual voltage and current being used. But you need normal multimeter etc and maybe some wire soldering. It also means that a 65W PSU that does USB-C PD won't output more than 3A at 5V if it is standards compliant I think. If the OP5+ tends to want to draw more than 3A, the PSU might drop voltage (e.g. even 0), I don't know.

The big questionmark(s) are still then: - can that PSU offer 5A at 5V? - does your OP5+ (and your specific Armbian installation) negotiate 5A at 5V? - or maybe does it negotiate e.g. 15V with 3A ? I got also a 65W laptop type PSU, works fine with tablet/laptop, seen 15V being used. When using with a diskless (headless netboot netroot) RPi4B, it worked, but some undervoltage warnings, that aren't there when I power it with a PSU once bought together with a RPi3B+. So I guess more ripple or so for that 65W PSU and of course RPi4B does not support USB-C PD (only base 5V max 3A).

I think I don't believe that unless you post a similar serial log where we can see what U-Boot, kernel, etc is used. Board is: https://radxa.com/products/rock5/5c I have a RK3588S board running mainline U-Boot 2024.10 and kernel 6.12.6. Is headless (serial console) but if I connect HDMI, it runs KDE6 Wayland really great. I avoid ZFS, but use Linux native Btrfs. All runs from eMMC and/or NVMe. So my advise is, upgrade, maybe first try extra separate latest image from downloads, see if that boots OK. Then merge kernel+U-Boot from that into you non-working setup. That is manually copying things, but then likely no need to re-install everything.

My Rock3A was getting a bit further, so I could benefit from verbosity=7, although it got into trouble somewhere related to NPU (could not draw any conclusion from that anyway). I am looking for an extra RK3588 (not RK3588S) board, maybe OPi5, many options, need more study what is most effective w.r.t. 12V off-grid powering. After I looked into schematics of Rock3A it got more clear to me how I need and want powering. The Rock3A has on-board 5V 8A DC/DC converter, so as suggested somewhere, one can solder some power wires to a DIY USB-C male connector and connect those to something between 9V-20V. So no 'thin wire' problem at least. I should have looked at it before, as now extra RPI5 PSU is not needed now (but good as laptop/tablet charger etc).

I did a quick test based on my december 16th rock3a build tree: /local/s0/armbuild$ sudo btrfs subvolume snapshot rock3a orangepizero3 /local/s0/armbuild$ cd orangepizero3/build /local/s0/armbuild$ ./compile.sh BOARD=orangepizero3 BRANCH=edge kernel-config and also there in the kernel menuconfig Virtualization is not selected, also not the setting 1 level deeper. But when selected, the .config is as expected (like other 64-bit ARMs). My build-host is NanoPi-R6C (RK3588S) running Armbian Bookworm (beta repo, 6.12.6 kernel) where that armbuild folder is 30GB btrfs space on NVMe.

I see that for my 64-bit ARMs (rk3588 rockchip64/rk3568 bcm2711) the kernel configs have the following which allow me to use KVM/libvirtd/QEMU: /local/s0/armbuild/rock3a/build/config/kernel$ grep KVM linux-bcm2711-current.config CONFIG_HAVE_KVM=y CONFIG_HAVE_KVM_IRQCHIP=y CONFIG_HAVE_KVM_IRQFD=y CONFIG_HAVE_KVM_IRQ_ROUTING=y CONFIG_HAVE_KVM_DIRTY_RING=y CONFIG_HAVE_KVM_DIRTY_RING_ACQ_REL=y CONFIG_NEED_KVM_DIRTY_RING_WITH_BITMAP=y CONFIG_HAVE_KVM_EVENTFD=y CONFIG_KVM_MMIO=y CONFIG_HAVE_KVM_MSI=y CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y CONFIG_KVM_VFIO=y CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y CONFIG_HAVE_KVM_IRQ_BYPASS=y CONFIG_HAVE_KVM_VCPU_RUN_PID_CHANGE=y CONFIG_KVM_XFER_TO_GUEST_WORK=y CONFIG_KVM_GENERIC_HARDWARE_ENABLING=y CONFIG_KVM=y CONFIG_PTP_1588_CLOCK_KVM=y For 64-bit Allwinner (I only have 32-bit Allwinner SoCs): /local/s0/armbuild/rock3a/build/config/kernel$ grep KVM linux-sunxi64-current.config CONFIG_HAVE_KVM=y CONFIG_PTP_1588_CLOCK_KVM=m I do not know the details, but already KVM IRQ ROUTING needs to be there AFAIR, otherwise hardware accelerated virtualization won't work.

Do as Werner says I think, although setting verbosity=7 in armbianEnv.txt will likely show you where it fails

This is "Orange Pi Zero 3 is powered by Allwinner H618 quad-core Cortex-A53 processor: I am a bit surprised that you needed own actions to enable KVM. At least already Debian Bullseye aarch64 had this enabled by default. I used that on RPi3 although that one can run 32-bit kernel then it won't work. I use standard KVM/libvirt/QEMU, no proxmox.

There is Debian Bookworm image as well. That variant should have been there for more than a year. Ubuntu Noble is fairly new, so maybe some issues. Kernel is the same. But vanilla Ubuntu Noble is kernel 6.8, so in theory there might be issues. I use Armbian Debian (kernel 6.6) on my 32-bit NEOs. no issues. I could switch to Noble but is no priority. I use it on a new Rock3A, works fine there. If you feel you can't handle potential issues, use Bookworm.