eselarm

I think it is clear now to me how the hardware is, I also took a look at https://www.friendlyelec.com/index.php?route=product/product&product_id=309 (scroll down to the PCB pictures layout and interfaces). Also your b1) and b3) info points help confirming and I see that this is yet another step in complexity (or just more options, it is great hardware) but I can't find where in Armbian config this is handled in a way similar to the script attached in the other topic related to Btrfs for rootfs. In addition I took a peek at the (for me) banned 'AI-bot' account 'Boardcon_yang' and again see rubbish hallucinations. I understand that Boardcon is a real company, but my take is to avoid that company as a plague because simply this is how they deal with individuals/humans then apparently. Also Armbian should do something about it. Same as AI generated videos/pictures that are on social media (I am not, all blocked, I even do not have a big-tech Microsoft github account), it should be marked as such. Else it will be like email spam boxes: block all except the ones clearly human still or just not use Armbian and this forum anymore. So back to the issue: Is a matter of what you want or more difficult, what is wanted/done by Armbian and the people/organizations/companies doing the financial backing. There are (I think) 6 Linux block devices that could contain the bootloader or a part of it (a version of U-Boot in this case): sda sdb sdc sdd SD-card SPI-NOR-flash sdd is new to me and don't know what that shall be used for. It can easily take months or years before it is known in general what is a practical way of working for an individual (so non-profit, users at home for example). For professionals/industry there might be a exchange of info under Non-Disclosure-Agreement, so can be all clear, like Android system builders. Those also need large volume management of systems, at least end-users are certainly not the admins of the things they use. It might be even forbidden by law as is known from telcos (depends on country). The question is what the ROM code in the RK3576 does based on how the M5 HW design is, it is usually some signal level that determines which device is read first or check for a bootloader of some stage. You need documentation then, look in schematics of the board, but then still it might be unclear what steps the ROM does at power-on. If you have used the board with other OS earlier, that one might have written a version of its bootloader to SPI-flash (/dev/mtd0) for example. Compared to other already well-know SoCs/boards like ROCK5B, it is clear that SPI-flash offers the best options like we know from PC's: So you have like a BIOS setup as it can store variables about the OS there. I do that on my ROCK5B as it has SPI-flash only (or SD-card). My NanoPi-R6C has no SPI-flash, just soldered eMMC and with the current U-Boot variants does not offer the variable storage, so I need a sort of own hack/method to switch OS. So for the M5, I would boot with Armbian from SD-card, then wipe all (boot) areas from all devices and use a manual method to flash the Armbian U-Boot to SPI-flash. That is different from what is done in the other topic as there a combination of sda and sdb is used and also is in the UFS install script for the M5. But also SPI install method is there. It is in /usr/lib/u-boot/platform_install.sh The file for SPI is then /usr/lib/linux-u-boot-current-nanopi-m5/u-boot-rockchip-spi.bin and command would be: flashcp -v -p --erase-all /usr/lib/linux-u-boot-current-nanopi-m5/u-boot-rockchip-spi.bin BUT I do not own an M5, so it is just based on what I did last week for my ROCK3A a few times with own build U-Boot (with Armbian build framework) and using also various kernels. Everything related to M5 fails for me as I do this trials in a quick container run. You need to read info and as long as it is unclear to you keep studying and/or wait until the armbian-config tool helps you doing it correctly. You are correct that the script in the other topic is mainly an issue about wanting Btrfs for rootfs. You might not need Btrfs for root now, but having it allows you to manage the installation (so Armbian in this case) and especially the sizes of the block devices/partitions all to be done in the running system. That saves you from quite some boot time issues, as for example you don't need another temporary OS/system to boot with, like it is known as 'Live-CD-ROM' for PC's for example. Also saves money as you can fit a lot more on 1 fast UFS or NVME etc. I use it on all computers, even decade old RaspberryPi1, so can do upgrades etc from my desk or while traveling by train remotely, SD-card just stays inserted and also board is kept powered on via PoE as it is outside in difficult place and might be bad weather.

quick check: # strings /usr/lib/linux-u-boot-vendor-cm3588-nas/u-boot-rockchip.bin | grep "U-Boot SPL 20" U-Boot SPL 2026.07_armbian-2026.07-Sece3-P1c54-H1a10-V102f-B5da4-R448a (Aug 14 2026 - 13:26:47 +0000) which is very recent, not the old 2017.09 we see still quite often for RK3588 based devices, so if also the binary is actually used for booting (so written in SPI-flash or other bootloader device area), then I would say new mainline based kernels should work.

It depends on bootloader and surroundings if it works without action and/or issues. So also DeviceTree and overlays (if you use them). In general, if the CM3588-NAS is considered as a traditional PC, so just 8-core ARM64 CPU and no special Rockchip function block like HW video encoder used/needed, it is no problem to use a latest mainline based 7.x kernel. Even simply vanilla Debian kernel from Debian Sid works fine. I do that for my RK3588 SBC's mostly as for example for Jellyfin I hardly have/watch video's that need HW based video encoding. I use EDK2-UEFI v1.1 as bootloader, then no issue to use 7.x kernels, but a recent U-Boot is also fine if headless (no HDMI at power on). I also use grub-efi, so also same as PC's. Make sure you understand and/or have that in-place, as it allow easy switching the used kernel at power-on, you might need a serial console in order not to be blind for what is happening and able so select adhoc.

UFS is presented as SCSI /dev/sdX kernel names and is not related to SATA (also USB-stick would appear as /dev/sdX name). NVME and SD-card/eMMC both use different names. I see from the script in https://forum.armbian.com/topic/60020-nanopi-m5-2651-ufs-install-btrfs-root-does-not-boot-and-manual-partition-layout-is-not-available that bootfs and rootfs is not special compared to just SD-card, but U-Boot seems different although all covered by the standard Armbian U-Boot install script function. The confusion might be, also for me as I don't own UFS, is the four different sdX devices. I have a similar issue with my NanoPi-R6C where, in the eMMC, there is also 2 extra bootX block devices that can be used for bootloader objects (A and B schemes etc). They are normally not used, but now for UFS maybe, I don't know for real, but from the script one can derive certain things. Also I have not looked into the mentioned 26.8.1 GNOME image w.r.t. the write_uboot_platform_ufs in /usr/lib/u-boot/platform_install.sh, but that is needed if I would own a M5. At the moment, I think more of the 4 sda, sdb, sdc, sdd devices (what is what), kernel might do random order, at least Debian based distros do that, I know openSUSE usually has the device named sda, so the first, for the OS and other HDD's or so in a computer sdb, sdc, sdd, etc. But to have it more predictable, there is: root@rock5b:/dev/disk# l total 0 drwxr-xr-x 9 root root 180 Oct 26 16:23 ./ drwxr-xr-x 20 root root 4.5K Oct 26 18:27 ../ drwxr-xr-x 2 root root 880 Oct 26 18:27 by-diskseq/ drwxr-xr-x 2 root root 2.0K Oct 26 18:27 by-id/ drwxr-xr-x 2 root root 160 Oct 26 18:27 by-label/ drwxr-xr-x 2 root root 240 Oct 26 18:27 by-partlabel/ drwxr-xr-x 2 root root 620 Oct 26 18:27 by-partuuid/ drwxr-xr-x 5 root root 1.2K Oct 26 18:27 by-path/ drwxr-xr-x 2 root root 240 Oct 26 18:27 by-uuid/ Example, yesterday, I had to use a 'by-partuuid' path for iSCSI target in my ROCK5B as the underlying Samsung SSD is virtualized now (so /dev/vda instead of /dev/sda) and the 'by-id' is empty then.

Done this, with the difference no local hacking grub.sh anymore as $ARCH=arm64 (so no failure where topic is about) AND this is with both PR#11072 (already merged) and PR#11084 in effect. The build option BOOTPART_REQUIRED=yes needs removed, so this: ./compile.sh build BOARD=rock-3a RELEASE=trixie BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes NETWORKING_STACK=systemd-networkd FIXED_IMAGE_SIZE=2048 BOOTFS_TYPE=fat ROOTFS_TYPE=btrfs BTRFS_COMPRESSION=zstd COMPRESS_OUTPUTIMAGE=sha EXTRAWIFI=no KERNEL_CONFIGURE=no KERNEL_BTF=no KERNEL_GIT=shallow ENABLE_EXTENSIONS=grub-with-dtb GRUB_FDT_FILE=rockchip/rk3568 -rock-3a.dtb UEFISIZE=100 succesfully generates the desired image. However, without detail knowhow about grub config revert to normal Debian, not a workable solution as terminal I/O is muted and grub menu skipped. As my real rock3a is busy/used (and also there is no (UEFI) bootloader build with the image), I started the image in a KVM I call 'armbian64' just swapping normally used image with this new build. The method is then to hit edit in grub menu and ad-hoc remove the devicetree line as that is for HW rock3a and KVM does not need any, just all virtio. But no grub menu, so same as for real nanopineo revert to standard Debian grub config with a few edits like loglevel=7. Then all fine. Good thing is that also this time, my VM is know by my router, so after with a bit of ssh wiping I could login as root:1234 and immediately fix the grub and serial stuff. I think the idea behind this terrible grub config (for me) is to have the same as U-Boot boot.scr: no debug scrolling, hopefully a logo and no kernel selection. That seems fine if the boards only option is UEFI and no U-Boot or free open source bootloder (e.g. RPI), but people use grub so they can make selections at boot/power-on, not only kernels, but also multiple OSses. Maybe not for tiny 10-year old SBC's, but certainly for high end like RK35xx.

Something happened to the file below while installing and remove packages: root@ekker:/etc# stat armbian-leds.conf File: armbian-leds.conf Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: 0,28 Inode: 42402 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2026-10-23 14:39:59.268000002 +0000 Modify: 2026-10-23 14:39:53.194144084 +0000 Change: 2026-10-23 14:39:53.194144084 +0000 Birth: 2026-10-23 14:02:59.333152304 +0000 root@ekker:/etc# date Fri Oct 23 15:10:41 UTC 2026 So now with empty file of course no leds problem. I will add snapper and change subvols so I can better track what is happening.

I see it is actually a failure for the 7.3.0-rc7-edge-sunxi kernel (with my extra setting CONFIG_EFI=y), just full log from armbian-debug here: https://paste.armbian.com/ucitawavax [ 1.526902] leds-gpio leds: error -EBUSY: Failed to get GPIO '/leds/pwr' [ 1.526958] leds-gpio leds: probe with driver leds-gpio failed with error -16 and already: root@ekker:~# systemctl status armbian-led-state.service * armbian-led-state.service - Armbian leds state Loaded: loaded (/usr/lib/systemd/system/armbian-led-state.service; enabled; preset: enabled) Active: active (exited) since Fri 2026-10-23 14:03:16 UTC; 27min ago Invocation: b071139a57234fb7a65ef3dc88c4534d Process: 376 ExecStart=/usr/lib/armbian/armbian-led-state-restore.sh (code=exited, status=0/SUCCESS) Main PID: 376 (code=exited, status=0/SUCCESS) Mem peak: 1.3M CPU: 485ms Oct 23 14:03:06 ekker systemd[1]: Starting armbian-led-state.service - Armbian leds state... Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:blue:status/trigger could not be restored Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:blue:status/invert could not be restored Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:green:pwr/trigger could not be restored Oct 23 14:03:16 ekker armbian-led-state-restore.sh[376]: warning: /sys/class/leds/nanopi:green:pwr/brightness could not be restored Oct 23 14:03:16 ekker systemd[1]: Finished armbian-led-state.service - Armbian leds state. So seems a matter of a new or wrong path for the leds or pins, where the older Debian kernel does is correct, also the leds config file is correct according to my understanding. Long time ago I disabled blue led of my rock-3a, so remenber a bit. Probably I install current sunxi as well (6.18) and see what that does. EDIT: sorry too fast, this won't work as it has no EFI enabled, so needs then booted via boot.scr or extlinux

To my surprise, the board also boots OK with the standard Debian Trixie 6.12.113+deb13-armmp kernel. Noticeable difference is quite a long pause between EFI_GRUB stub messages and kernel starting to spit out messages and that the red LED is constant on and green blinking as sort of activity. I prefer no LEDs on at all during normal operation, but this is a minor issue and likely some Armbian patch for sunxi puts them off. Of course Debian delivers no overlays, so the actual use-case is then 0, as I need analog-codec, SPDIF, 1-wire at leasta and some extra UART as well, all from the header pins, but it is great that it behaves now 'as a small UEFI Debian computer'.

After another power-on, first removing the y2k timestamped ubootenv.var which I thought maybe stores things and not waiting on boot, it turns out the board (still) comes online, just took much longer. It might be due to netplan using some other systemd-networkd config then my own .network files, so as minimal I did: systemctl disable systemd-networkd-wait-online.service that is a bit more relaxing. But still no serial I/O Then I saw my usual edits to /etc/grub: GRUB_CMDLINE_LINUX_DEFAULT="loglevel=7" GRUB_TERMINAL="serial" GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1" where overruled by what is in: /etc/default/grub.d/98-armbian.cfg, especially GRUB_TIMEOUT=0, which makes you cannot select anything and that is reason I saw nothing when EFI compiled kernel. Earlier it just could not load the plain image kernel, so essentially the error menu. So the sledgehammer: mv 98-armbian.cfg 98-armbian.cfg.disabled systemctl set-default multi-user.target # an SBC with no connector at all for a screen/monitor should not default to graphical.target, 'it is defacto headless' Debian's default GRUB_TIMEOUT=5 is just too short in this case due to the error with 'com0' 'serial', I saw just a short flash of the grub menu, so made it 15 Also for GRUB_CMDLINE_LINUX_DEFAULT, 'splash' is not recognised and transferred to userspace. Plymouth I see as a real PITA, certainly purge all when CLI/headless, maybe it is 'plymouth.ignore-serial-consoles' that is the problem. So then update-grub: Generating grub configuration file ... Found linux image: /boot/vmlinuz-7.3.0-rc7-edge-sunxi Found initrd image: /boot/initrd.img-7.3.0-rc7-edge-sunxi Found DTB path: /boot/armbian-dtb-7.3.0-rc7-edge-sunxi Found DTB file, using it: /boot/armbian-dtb-7.3.0-rc7-edge-sunxi Found linux image: /boot/vmlinuz-6.12.113+deb13-armmp Found initrd image: /boot/initrd.img-6.12.113+deb13-armmp Found DTB path: /boot/armbian-dtb-6.12.113+deb13-armmp Found DTB file, using it: /boot/armbian-dtb-6.12.113+deb13-armmp Adding boot menu entry for UEFI Firmware Settings ... done Reboot, then all normal, all U-Boot, grub menu, kernel log, finally login prompt. Armbian-unofficial 26.11.0-trunk Trixie ttyS0 ekker login: root Password: root@ekker:~# cat /etc/update-motd.d/99-blank #!/bin/bash echo "" exit 0 This last thing confused me some months ago w.r.t. ssh login speed testing. After disabled all motd, still a linefeed, was not form ssh config or so, but this file. echo -n "" I would say, but maybe than other issues. The linefeed should be 'pre-' I think, not '-post' w.r.t. all the motd items. As brute force I just removed the whole folder as for almost exclusively unattended login normally, I anyway don't see what is displayed. W.r.t. ttyGS0 v.s. ttyS0, that is still unclear to me, but at least now I can select a kernel, also edit in grub menu to change a few things on command line ad-hoc etc, so much easier to test new kernels/configs (with or without DTB from kernel package).

I did some other test builds, 1 obvious thing is that FIXED_IMAGE_SIZE=2G should be FIXED_IMAGE_SIZE=2048, then image is 2GiB and not about 1.7G or so. Other thing that boot partition was 260 and not 256 is now fixed by https://github.com/armbian/build/pull/11072 Due to that, I looked into grub.sh and after several trial-error and hacking/removing some line locally from grub.sh I got a successful build. But as I already knew actually, a 128-entry GPT overlaps Allwinner H3 8k offset bootloader location. I did convert with gdisk to MBR but then partition error/not-found as grub looks for GPT, probably also a GUID and changing all to old MBR is possible I think, but might even need own grub compile, so no option. What works is to have or to convert the GPT to contain less entries, I set it to 16 (gdisk x or r menu then s). Then after sector 6 free space instead of sector 34. Then some other mutual exclusive issue is that having grub assumes vendor/board UEFI FW like Dragon6 or a PC. Or special EDK2 for RK358.8 ROM-only tiny SBC's nee U-Boot in EFI mode in order to boot an EFI based installation. So I had compiled latest U-Boot (for its Btrfs Zstd compression fix on 32-bit sunxi at least) so just wrote that .bin file at the bootloader offset at 8k Then SD-card started with the 2026.07 U-Boot build, seen via serial console cable and and nice blue kernel menu via screen in konsole on tumbleweed. Then next issue is the the Armbian sunxi 7.3.0.rc7 has no EFI_STUB, so rebuild kernel with that copied that so SD-card. Then it loaded the kernel and activity on the board, also ethernet active, but I did not see the blue grub menu anymore, it just booted the first entry silently after some seconds. No serial output at all, not more that this: Booting: Label: mmc 0 Device path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,7200000000000000)/SD(0)/SD(0) error: serial port `auto' isn't found. error: terminal `serial' isn't found. error: terminal `serial' isn't found. Booting `Armbian GNU/Linux, with Linux 7.3.0-rc7-edge-sunxi' Loading Linux 7.3.0-rc7-edge-sunxi ... Loading initial ramdisk ... Loading device tree blob... /@/boot/armbian-dtb-7.3.0-rc7-edge-sunxi But as this NanoPi-NEO has HW MAC-address reservation for mu DHCP server, IPv4 was know and I could ssh in as root with 1234. Then normal firstboot sequences so create user/password/localization etc. I think on another boot attempt I also saw 'com1' as serial port, so for sure something wrong there. First reboot did hang, later reboots went fine, is somehow known to me. So it all went remarkably fine, taking into account the many tweaks and hacks. So the build line I used (on ROCK5B running Armbian Trixie with 7.3.0.rc5 rockchip64 kernel ATM): cd /local/s0/armbuild/grubboots/build git pull git fetch origin pull/11072/head:pr-11072 git checkout pr-11072 ./compile.sh build \ BOARD=nanopineo \ RELEASE=trixie \ BRANCH=edge \ BUILD_DESKTOP=no \ BUILD_MINIMAL=yes \ NETWORKING_STACK=systemd-networkd \ FIXED_IMAGE_SIZE=2048 \ BOOTPART_REQUIRED=yes \ BOOTFS_TYPE=fat \ ROOTFS_TYPE=btrfs \ BTRFS_COMPRESSION=zstd \ COMPRESS_OUTPUTIMAGE=sha \ EXTRAWIFI=no \ KERNEL_CONFIGURE=no \ KERNEL_BTF=no \ KERNEL_GIT=shallow \ ENABLE_EXTENSIONS=grub-with-dtb \ GRUB_FDT_FILE=sun8i-h3-nanopi-neo.dtb \ UEFISIZE=100 Unfortunately, after a few extra reboots, networking did not come online, and as the serial console went dead after kernel+initrd+dtb load, I have no clue why, at least no DHCP request visible in router. I have doen update-grub, various changes in console= statement w.r.t. 'serial', but that is current a major showstopper. It is similar frustration as with RPI boards with older BCM SoC only have 2 UARTs and RPL kept swapping because BlueTooth etc so getting mainline to work is endless fiddling with serial parameters (if you try U-Boot or EDK2 on RPI4 for example). I also installed linux-image-armmp, but that did not boot. Not using the kernel package DTB did make LEDs blink differently, but no boot success. So my perception is that Allwinner H3 needs and uses many great Armbian patches in order to be usefull, which means it does not make sense (currently) to have 1 kernel that boots on both real HW and also in a KVM. So same as for RPI0-3 (when Raspbian), when the rootfs is booted in a KVM, select the generic Debian ARMv7 architecture kernel. For that I use apt pinning on Raspbian (as it is not ARMv7) but on Armbian 32-bit armmp can be installed in addition. When on real HW, I use extlinux folder on FAT (or just basic 1 kernel boot.scr), when in KVM with 32-bit EDK2 it sees EFI folder and uses BOOTARM.EFI and grub. This also makes me think that it might be faster to improve scripting around qemu-system-aarch64 using U-Boot native loading instead of EFI-based. I have it for 64-bit, only text-mode/CLI of course. I use Btrfs enabled Armbian qemu-uboot-arm64, it had/has no issues with decompressing Zstd at least. There is no 32-bit variant of that, so I'll have to see how that would work. 64-bit is all no issue AFAIK, the rockchip64 kernels also include virtio drivers same as standard Debian arm64, so runs in KVM/virt-manager without issue, nice same 1 flavor kernel. Maybe I do a similar build for rock-3a, disable SPI-CLK with jumper and then see if SD-card boots (when latest U-boot written to SD-card manually still).

'Spread around the world' means to me costs of plane tickets and hours lost in travel time etc, so for me it was/is an easy calculation: You can buy a handful of computers/boards for that money and also spend time to think about a dual-setup, e.g. a working link with x86 and devices under test. In the past for just 1000km distance (by car) I just changed ISP's/contracts at the 2 locations such that I got Fritz!Boxes (DSL, Cable modems build in), those have build-in (old fashion) VPN, so I could rather easily create my own OpenVPN and later WireGuard links as well. That was already a few hundred Euros, besides lots a time to figure out IPv6 issues etc. The latency was no real issue, but is just an example how to approach. And really is all DIY, as Linux computers, no support form computer shop what so ever. Nowadays, just at home I use USB serial UART/TTL console/debug cables and maybe a wall plug with some ESP/Tasmota so I can powercycle things. z8350 I have as well, they are low-power, same as RPI4, much better actually as everything with sleep/standby also works and LiPo battery included etc. So one known working computer is 'HID' via the serial cable on header pins 6 8 10 or dedicated extra generic USB-C cable even like for my NanoPi-R6C. So I can watch everything already at power-on, most important is U-Boot/bootloader. For your unknown SBC's the kernel-loading might just takeover buffer sizes w.r.t. on-board ethernet as that is usually initialized before kernel as U-Boot might want to do networkboot. That is just local, might be simple UDP so nothing complex with TCP windowing you will have to deal with at high latency. But is all guessing, you need at least a serial debug cable to start with, else you waste your time also with guessing. Then it is important to consider the HW I/O path what you already figured out already: USB is an extra layer, for sure has extra other/more buffers; you can calculate how big they will be or grow based on latency and speed. And not known by U-Boot, so likely own/new buffer sizes. Same can be the case for PCI-E connected RJ45, as mentioned ROCK5B has its 2.5GbE RTL chip like that, same as my NanoPi-R6C 'LAN' port. I use EDK2 UEFI with netboot disabled as I just have NVME inside, so I guess other buffersizes. Armbian on those high-end but low-power devices uses the same as on x86, I can use Armbian edge rockchip64 kernel or Debian sid generic arm64, makes no real difference, at least not for networking. Even more for userpace, it is both the same Debian Trixie arm64 packages and configs. However, if on-SoC ethernet, various the driver levels are different, and even per SoC. That is where you need to look at I think. Might be very complex and at kernel/uboot development level. Maybe something in DeviceTree, but not likely I think. You might also try 'the OS that came with the SBC', although I guess those are hopelessly outdated, but I guess same problem with high latency IP traffic.

No, maybe others know, I just had a look in Armbian space and I see something I did not know: https://armbian.com/vendors/linkease 1 is RK3568 based which I know from my ROCK3A, other I hadn't noticed before. Maybe use AI based search to get some hints. At least be aware that many ARM computer boards need proprietary drivers/firmware, so for something like an internet router where ISP's themselves consider 10 years operation/maintenance, it is quite a challenge to get that open-source based I think. That is why I focused on virtualization and less integrated HW solution.

Good you provided various links/info, unfortunately, it doesn't look good to me and I recognize several issues from my experience with mt7921u (as USB-stick). I have 2 of them, 1 with a brand name and one without a brand name. Should behave the same, but do not. I tried various setups, but I just can confirm what is on internet for several years already. My goal is coverage, so 5GHz not needed actually, but it is sold as also doing 5GHz, which I got working when client. As Access Point, I only can get 2.4GHz working and then still today now I see issues that I don't understand and thought were fixed with a kernel minor version upgrade, but that is another issue, nothing RF related (I think). So w.r.t. uwe5622, I can not really help you further. I have not looked into specific HW/architecture/design, but make sure you know how specs are marketed. Same as for myself, if you want solid WiFi, make sure you get something with a chipset or from a company that has proven itself for a decade or longer. Or accept that it is like it is and limit your deployment to what works. I personally stay away from something with DKMS, I actually removed the whole dkms from my Armbian installs as it causes too much issues in general throughout the years when using rolling release Linux. But if you already have the HW, maybe try a very latest kernel, build all yourself and hope it is something in the Linux kernel that causes the issue and not something related to unisoc firmware blob. The latter is closed source of course and may have a several updates and well documented what is fixed, or just a one shot and no updates. For my mt7921 for example, the bin/blob file has a name with different increasing timestamps, but contents are the same for years, doesn't matter if Debian or OpenWRT.

I assume then shared kernel. So might be interesting for OP as Proxmox/KVM does not work on Cortex-A9 but containers should (I think, never used container host 32-bit ARM). But I see no option to run OpenWRT (EFI boot) as KVM with Armbian/Debian/Tumbleweed/Ubuntu/RasberryPiOS as host. As indicated, OpenWRT is very small, not only on disk size. I see I have allocated the VM 1 vCPU and 512MiB. Less memory should also work, but not sure how low it can be. It is mostly the GUI that needs RAM I think as the kernel+routing is very small, should be somewhere 50MiB to 100MiB I think. At least if only speeds up to 100Mbps or so and low latency. Also which CPU type (Cortex-A55 or Cortex-A76) is up to libvirtd/QEMU/KVM as this was with mainline based kernel on RK3588, that does not need CPU pinning. For 32-bit guests, I use RPi4 (Cortex-A72) or ROCK3A (only Cortex-A55) as 32-bit does not work at kernel level on Cortex-A76. Related to that, a NanoPi-R76 (RK3576 based) might also be an option for OP as that is bigLITTLE Cortex-A72 + Cortex-A53, still ARMv8.0 but great low-power. An option is then that the whole storage/image of the clearfogpro is put as a KVM on the RK3576, although with different bootloader and kernel (EDK2 and some Debian armhf kernel). Is for people who have some well working 32-bit and fear the transition to 64-bit (so redo whole userspace tuned for many years). Indeed, various possibilities; added to that is that I also have used 4G as DSL was in kilobit speed range and 4G is just IP packets, although I put those on VLANs, so to have smooth transition between DSL 4B fiber (so multi-WAN in fact). I'll will need a test install then to see what it is. I know the GUI's from some managed switches, was difficult to figure out what is meant with what, but after that and having done the same in Opensuse Tumbleweed years ago on RPi4 with 'wickedd' networking and also Ubuntu 'netplan.io', it was a relief to just use 'sudo nmtui' to create a bridge with enslaved VLAN. And that can be done via a serial console cable, so I prefer that as no HDMI monitor+cables needed then, just a laptop, good for panic/trouble situations to keep things as simple as possible IMO. Even Rj45 can be unconnected initially, only power needed. More complex but maybe also interesting is if IOMMU works on the host computer. Is no problem on e.g. N100 boards, but for RK3588, I could not get it to work (yet). Also makes little sense as for example the NanoPi-R6C has only 2 PCI-E devices that could be mapped from host to guest: NVME and 2.5GbE. But NVME is needed for high speed I/O for Armbian Build and VM image storage and I have no 2.5G switches (yet) and also network virtualization works very well if Linux as virtio network driver or a virtual intel 1000e (so then FreeBSD is also no issue).

This it makes little sense, it is just totally different HW and I am quite sure the problem in this topic is related to HW / drivers. I see in you 1 year old armbianmonitorlog: [ 3.039362] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! [ 3.039448] rockchip-pcie f8000000.pcie: probe with driver rockchip-pcie failed with error -110 BUT it takes me too long to determine what actual HW SBC this is about, yes Rockchip based, but what brand, series, HW revision, etc, etc. Also what U-Boot, maybe you still have some old illegal one as the first topic line suggests. This is really a no-brainer compared to the topic issue and also depends on which HW/SBC it is. Some need extra udev rules, some might handle it in systemd-networkd. But easy to change yourself, I have done it several times as it fits my preferences better, depending on what computer it is. You need to do that yourself if you plug in extra RJ45 devices for sure. So can you provide: - U-Boot log via serial console UART TTL cable? - an URL to the vendor HW and a version number of your specific HW revision ? What does this mean? And it seems USB2, so half duplex down to the lowest level of the chain. Or not? I can add more confusion, for example why don't you build/compile a latest kernel (7.3 based) yourself and also latest U-Boot (so select edge or bleedingedge branch). I have several of my Armbian Trixie devices with 7.3 or 7.2 rockchip64 or sunxi kernels. Or you run just standard Debian Unstable/Sid kernel version and compare. Maybe there are buffer sizes somewhere that matter, but is up to you to report, only then maybe others can suggest what to do or change.

I see from http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/orange-pi-4-LTS.html that it is 'dual-band', but what what works might depend on how you use the WiFi subsystem. It seems to me the -LTS is a cost-reduced/optimized variant of the non-LTS. At least completely different WiFi, that needs attention. Have a look at the firmware, how it is loaded and if it can do scanning, so sort of auto select band. In theory does not have to be, but lot more info is needed then.

Does this suggest to use same kernel for host/HW as the router instance? Also, how do you make sure 'LAN' and 'WAN' are separated, to the same level as when using something with 2 physical ethernet ports? I use nmtui mostly to create a basic set of ethernet devices on the host and then in virt-manager I allocate 2 (known) MAC addresses to the VM that is then used by for example OpenWRT VM or Opnsense VM or something else the same way as a real HW/ISP router. If not same MAC address for the WAN side it takes an undefined amount of long time before DHCP on the WAN side succeeds. There is a lot more to deal with w.r.t. my ISP, but that is too much off-topic detail. Or could be even plain qemu-system-aarch64 with a lot of options, but only used that for just 1 ethernet port, e.g. like testing Armbian image boot with U-Boot for HW/SBC I don't have myself. For containers, so 'shared kernel', I usually use a btrfs subvolume snapshot of the Armbian rootfs itself, so I have all settings/preferences in a blink of an eye and use systemd-nspawn to start it. If plain/vanilla systemd-networkd on both host and guest, there is /usr/lib/systemd/network/80-container-host0.network file that, if put in /etc/systemd/network/ and changed with: [Link] MACAddress=<MAC-address> presents the correct/needed MAC address, but it is the same broadcast or PHY link so not usable for 'router'.

I now see the clearfogpro is 2x Cortex-A9 based, not the newer Marvell SoCs with Cortex-A72. Cortex-A9 has no HW virtualization, so the board is rather dedicated router only then. Despite having lots of networking HW, I would prefer some other 64-bit capable SBC. I personally have separated 'WiFi' and 'routing' as for WiFi I want the best location(s) in/around the house. I am using the standard Linux virt-manager which is available by default in all 64-bit distros, runs even OK on RPI3 (4x Cortex-A53), although SD-cards can be bottleneck. OpenWRT has images that are tailored for RPI 64-boards, and the funny thing is that it is basically 2 partitions, 1 boot and 1 root. I had to look twice at the size numbers, but the root is really only 128MB diskspace while the boot is same or bigger but mostly empty (that is due to what is common how RPI boots). For a generic EFI variant boot is or can be much smaller. If U-Boot is used, it would/is not much more than that 128MB. I used it as test in a KVM (just CLI virsh tooling) on RPI4 to figure out issues with an MT7921 series USB WiFi stick that I use as extra AP. In the end at least Armbian rk35xx vendor 6.1.115 showed issues where a mainline based did not. Now with 6.1.172-vendor-rk35xx build few days old no issues anymore. So my experience is, with some VLAN capable switches and fiber2ethernet box supplied by ISP, router can be anywhere, assuming that you know how to handle VLANs and bridges in Linux. And make sure mainline kernel and generic/standards as much as possible. A lot depends on what speeds you want. RPI3 is '~50Mbps half-duplex single stream'. But ARMv8.2 like RK3588 boards should have no issue with almost full 940Mbps full-duplex even with Wireguard etc all in a KVM. I haven't tested it as I try to keep lowest price for (fiber) internet so don't have the full 1Gbps speed. Also low power as much as possible. Last week I did some measurements at USB-C connector level with my NanoPi-R6C: with 2024.01_armbian U-Boot and 6.1.172-vendor-rk35xx kernel+dtb I got it down to 1.15Watt idle. That is with Armbian Trixie running from Samsung 970 NVME. And temporary both ethernet ports set off-line. With the 1GbE (labeled 'WAN)' on again full-duplex 1000Mbit/s it is about 1.4Watt idle. Half-duplex 10 Mbit/s was 1.23Watt idle or so. If I run an Armbian Build on it, it is of course max at about 10.5Watt or so. Also interesting is that if only base 5V input, you don't loose about 20% in the onboard DC/DC conversion (when USB-C PD input is 20V or 15V). Of course those numbers only matter if longer period of battery operation. To compare: I had an old APC UPS that takes a constant 7W by itself. My old BananaPi-M1 (2x Cortex-A9, SATA on-board, GbE) is 1.7W idle AFAIR. I soldered a LiPo to it, so it is its own UPS as well. SATA is down however when running from that LiPo battery. I have looked at Radxa Dragon6 as this can also be powered by very wide range of input voltages, but it cannot charge a LiPo when you solder it to it, so although faster than RK3588 boards, also due to high RAM/storage prices, I did not buy one.

There are recent Armbian images and Armbian standard support, see https://armbian.com/boards/clearfogpro How to make a 'router instance' is something generic Linux, almost anything is possible.

As a test for yourself, you can power-on the SBC with no SD-card inserted. Then look if something is in UART serial console log. Also, you mention 2 Linux OSses worked, in general, you should have a backup of those, so with either of those you can wipe SPI (and eMMC). If you don't have a backup, you will need maskROM mode, so you need another cable and reading how that works for the OPi5Pro. Nothing magic, just time-consuming and no fun, but others (and yourself) can't guess what is programmed in the bare board. And what PSU you use, if that is OK or not and what SD-card, if that is OK or not and maybe also the USB-SD-card writer might be an issue, we have seen that on this forum for example, I still remember as that very well.

That package is in standard Armbian Trixie, a test run on my NanoPi-R6C: root@ranc:~# apt install linux-u-boot-orangepi5-vendor Installing: linux-u-boot-orangepi5-vendor REMOVING: linux-u-boot-nanopi-r6c-edge Summary: Upgrading: 0, Installing: 1, Removing: 1, Not Upgrading: 2 Download size: 920 kB Space needed: 3423 kB / 5394 MB available Continue? [Y/n] BUT, I see it is also 2026.04_armbian, so I am a bit surprised by that. The 'legacy' can also be installed the same way (what you did) and indeed 2017.09. I expected that to work, I use also that version on my ROCK3A, else I can't get NVME+SATA working at the same time. I am out of ideas w.r.t. this armbian U-Boot variants, but as I mentioned earlier in this thread, EDK2 UEFI v1.1 is also an option. I use that on both NanoPi-R6C and ROCK5B, now in mainline mode, but you can set it to vendor in the settings, that it should run 6.1.115 kernel.

OK clear; also I see I made an error ~586sec is about 10m not 6. Anyway, if you want to run Armbian you have now on SD-card to run from NVME, I would take the older U-Boot package 'linux-u-boot-orangepi5-vendor' and write its binary to SPI-flash (or first try SD-card only) with armbian-config, that I expect to work. Then you have vendor U-Boot and vendor kernel. What is wrong with the mainline based U-Boot for OPi5, I really don't know. Mainline U-Boot on SD-card and mainline based kernel maybe detects NVME, but depends on what your OPi5 should do if that is OK for you.

Great that you found the report. Luckily it is 'high-level' SW issue, not a complex HW issue, like power or clocking w.r.t. devicetree etc. If you want to use very latest kernel, for many things running it in a VM works great. I cloned the Armbian installation from my NanoPi-R6C eMMC into a 16G .raw image file I think about almost 2 years ago and still use that to try 'risky' things, on the NanoPi-R6C itself, of course generic bootloader, but kernel can still be rockchip64. Even amazing that host runs rockchip64 4k pages bleedingedge while guest Armbian Trixie with Debian Sid 16k pages kernel. What also works is let the ROCK5B use 6.1.115, so all HW video encoders at 8Kp60 speed available etc and then CPU-pin a VM at 0-3 to have a sort of quad-core C-A55 or 4-7 to have fast C-A76 engine. So as KVM then for example 8G RAM vanilla Debian Trixie (6.12 distro kernel) using 8T HDD block storage provided by the ROCK5B via LVM/LUKS. Although there it gets tricky as LVM caching needs manual options for blocksizes, so currently 16k pages is a showstopper or needs partial recreating the storage objects, something to think about carefully and emulate/simulate before real HW.

2 remarks about the kernel log: - why is 1st timestamp not 0, but already about 6 minutes ongoing: [ 586.150768] Booting Linux ... - then I see several: rk-pcie fe190000.pcie: PCIe Linking... LTSSM is 0x3 I remember having seen this at least once in the past for a OPi5 or so I think with also boot fail, but I have no clue what it is, never seen in my 2 SBC's (RK3588 and RK3588S) But your U-Boot log is more important; that should enable PCIE of course. But topic title/subject is related to MTD, you only use SD-card and it already fails. So could be different root cause. Maybe make sure SPI-flash/MTD is empty, it might be it is not. For example, it could be doing all sorts of code execution (in that 6 minutes) and then hand over to SD-card.

I get this: root@rock5b:/local/s0/tmp# uname -a Linux rock5b 7.3.0-rc5-bleedingedge-rockchip64 #1 SMP PREEMPT Sun Sep 27 20:55:01 UTC 2026 aarch64 GNU/Linux root@rock5b:/local/s0/tmp# losetup NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop0 0 0 0 0 /local/s0/tmp/debian-13.7.0-amd64-DVD-1.iso 0 512 root@rock5b:/local/s0/tmp# mount | grep loop0 /dev/loop0 on /local/s0/tmp/1 type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048,iocharset=utf8) root@rock5b:/local/s0/tmp# find 1 | wc 9461 9461 428610 So seems OK. EDIT: Now also looking into https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/fs/isofs/namei.c?h=v7.3-rc5I see this rc5 has the fix, so no surprise I can't reproduce.