eselarm

works for me using wget in Linux terminal

I have been using 64-bit x86-64 and aarch64 virtual machines as router since 2016, in combination with a simple managed switch that separates and/or combines VLANs depending on ISP and physical connection (ADSL, 4G, fiber). Currently RPi4 where the router VM is 2 cores and 768MiB and connects to 'LAN' and 'WAN' VLAN/bridges. I can still max download at 350Mbps which is my max fiberspeed. I also have a NanoPi-R6C that can replace the RPi4 eventually, it currently serves as faster clone/backup/development, like routing everything via 4G smartphone for example.

I think you might need to have Secure Boot disabled. It might be enabled by default in newer UEFI firmware.

Yeah what version... You need to be more precise, but I guess you don't have a serial console/debug cable connected so you can show at least yourself what the board is doing. This way, at least I can't help you. Also you can interrupt U-Boot and via commands (see U-Boot help on various websites) check for existence of storage interfaces/devices. It is before the kernel is loaded.

So SPI flash is not all zeros, you have it filled with that U-Boot version. In the log I see mmc0, but I might be that this old U-Boot in SPI flash somehow hides it. I would make sure you boot a mainline U-Boot. You need a serial console cable to check which U-Boot from which device is loaded and used.

I assume 'without success' refers to: all zeros in 'SPI flash chip'. There could be other effects as well. All Armbian Rockchip kernels have eMMC (just '/dev/mmcblk*' essentially) fixed/builtin in the kernel so in vmlinuz, no initrd or overlays needed. I don't know OP5+ HW, but note that you can have 3 bootable storage devices on a Rockchip based SBC where U-Boot can be loaded from. So besides SPI, also eMMC and/or SD-card can contain a U-Boot bootloader (see first 16MiB of those devices). If so, then the question is what version of U-Boot? Besides lacking a mmcblk dev, like is the case for example if I use an old version of EDK2 UEFI on my NanoPi-R6C (RK3588s) on the eMMC(!), It might be that a mainline U-Boot version does not work with vendor kernel. I had that for my Rock3A for example (kernel crash).

If your userspace is also still Bullseye, you have to provide more info or just figure out yourself. I updated my BananaPi-M1 earlier this week, but runs Bookworm. I need to look-up what U-Boot I have installed, but I have a serial console cable permanently connected to another SBC, so in case it does not come online (no IP connection), I look at what the serial console port spits out. That is what you also need to do I guess. Kernel 6.6.75-current-sunxi work fine for me, was unattended upgrade+reboot.

At least the Armbian U-Boot .deb packages and also what is written in the image bootsection between partition table and 1st partition is not capable of reading Btrfs. So If you want Btrfs for root filesystem, you need 2 partitions: a first small one formatted FAT or Ext4 for boot files (kernel, initrd, DTB, overlays) and then 2nd for rootfs Btrfs formatted. I constructed this manually for my old 32-bit NanoPi-NEOs, in the past, but if you do a custom Armbian compile/build selecting Btrfs for rootfs (also with additional Zstd compression) it gets all done out-out-of-the-box. If you want a single partition, build U-Boot yourself, with BTRFS enabled. It are 2 settings you need to set to YES. Then write that binary to the bootsection and it can read boot.scr (and armbianEnv.txt. etc) from that 1 single Btrfs partition. I can lookup some old topics here on the forum, I currently keep a 2 partition scheme as I use various U-Boot blobs (also from Radxa) so an extra FAT partition is a bit more failsafe when all there is a serial console cable. It also is then the same as a UEFI system, that also needs a FAT formatted partition where a bootloader and/or bootmanager is located.

Ran a build, it packs overlays: [🌱] Packaging linux-dtb [ rockchip64 linux-rockchip64-edge ] [🔨] [ 21M] /local/s0/armbuild/rock-3a/build/.tmp/work-efccbebe-0297-4492-8451-549f4047d14e/kernel_dest_install_dir-w5E9G/dtbs [🔨] └── [ 21M] rockchip [🔨] ├── [ 75K] overlay [🔨] │ ├── [1.9K] hinlink-h88k-240x135-lcd.dtbo [🔨] │ ├── [7.2K] README.rockchip-overlays [🔨] │ ├── [ 459] rk3308-b@1.3ghz.dtbo etc. /local/s0/armbuild/rock-3a/build/output/debs# dpkg --contents linux-image-edge-rockchip64_25.05.0-trunk_arm64__6.14.0-S38fe-D0000-P6158-C3a01H3d80-HK01ba-Vc222-B9bbb-R448a.deb | grep "rockchip/overlay" | grep README -rw-r--r-- root/root 7355 2025-03-30 11:34 ./usr/lib/linux-image-6.14.0-edge-rockchip64/rockchip/overlay/README.rockchip-overlays So my local build is fine; seems something wrong in the 'Armbian build cloud infrastucture', I don't know anything about that.

Indeed they are copied or symlinked there from .deb package: linux-dtb-edge-rockchip64 But also that package does not include any overlays. I (re-)installed this linux-dtb-edge-rockchip64 package again now (trunk.313 instead of trunk.311 yesterday) and also that package lacks overlays. E.g. check with: dpkg -L linux-dtb-edge-rockchip64 | grep "rockchip/overlay" So even that there are 2 Armbian packages containing the same set of dtb+dtbo files, none of those 2 edge packages contains overlay files. So it seems something wrong in Armbian build, maybe only packaging, maybe even they are not build/compiled. This is actually a test for my Rock3A (or new/extra RK35xx still not purchased) to see if I can work with mainline kernels instead of vendor (6.1.99). Note that for 'vendor' the overlays are there. 'current' I don't know, I do not use it at the moment.

I did upgrade my NanoPi-R6C and see that there are no overlays in the linux-image-6.14.0-edge-rockchip64 Debian package; they were there in 6.14.0-rc4-edge-rockchip64 So there is no folder: /usr/lib/linux-image-6.14.0-edge-rockchip64/rockchip/overlay Is this on purpose or some mistake?

It all depends on that specific SBC and lowlevel init code. I don't know your board and maybe you changed U-Boot. But a high-level mitgation is to makes sure you set a MAC address in a NetworkManager connection file, see /etc/NetworkManager/system-connections

OK, this is great, sounds logical that KMS somehow needs to be used but I did not realize. A quick test on my NanoPi-R6C dumping to a .ts file (format mpegts) with ffmpeg from the jellyfin ffmpeg7 Debian package works fine, that is: I use multi-user.target, so CLI only, therefore only clear screen with Armbian bash login prompt with blinking cursor. CPU load is almost 0, CPU clock 408Mhz. The Armbian installation is Bookworm with beta repo enabled, and I know it runs KDE Plasma as well since some months (with both latest vendor and latest mainline kernels). I have not looked at panfrost, I probably did half a year ago, but will need to look at my notes. So it is mainly an out-of-the-box action, except the installation of external jellyfin ffmpeg7 which has rkmpp included. There might indeed be performance issues, but that is not really a surprise to me; An RK3566 is a cost-cut, lowest cost RK35xx, only (lower clocked) 4x Cortex-A55, you cannot expect too much of it compared to 4x Cortex-A55 + 4x Cortex-A76 + faster DRAM, etc found in RK3588. It all depends on what else it running, e.g. libreoffice slideshow or a heavy game.

I am sorry, there is a fatal typo in my sentence; the word 'no' is missing of course. It is like a Faraday cage of course; will edit the sentence

The idea is, at least mine, that you do not use the hole to srcew/fix the antenne, but just use the hole to put a uFL connector pigtail wire from outside to inside the casing. How and what you do with that wire outside I see as trivial issue. The main key point is that there is a no way to have whatever antenna inside the metal casing. A good enough WiFi antenna is just a piece of PCB with the correct metal structures on a tiny coaxial wire with a uFL on the other end that you click on the (M.2 E-Key) WiFi card. Many plastic casings for N100 or so have that PCB just inside with a bit of hot glue. So for metal casing glue it outside somewhere. It is not a matter of 'modern' or 'ancient', it is more that people let themselves fool in thinking that you need those 'modern' things. Indeed you can move the 3D spacial diversity position better in a consumer product, but that assumes that the end-users does better than (MIMO) algorithms in the chipset. There was a time that people only wanted a mobile phone with an 'antenna sticking out'. Even dummy plastic stick/extension worked for higher sales.