eselarm

Now I realize that as shown in the video, the BPI is powered the wrong way see https://wiki.banana-pi.org/images/4/45/Banana_pi_BPI-M1_1.jpg https://wiki.banana-pi.org/Quick_Start_Banana_pi_SBC Powering shall be done via the microUSB connector that is between the SATA power connector and the SATA data connector. Or via GPIO pins.

I used this image as base and from there did in-place full-upgrade: It used to lock-up with a kernel crash after 2 - 3 days, kernel 6.6.44 till 6.6.75. I have no HDMI connected anymore, only serial console cable, SD-card, microUSB power, RJ45 and SATA 8T HDD. Now with kernel 6.12.20-current-sunxi uptime already 6 days. I have radically modified partition setup, use Btrfs for rootfs, I do not use Armbian initial repartition scripts, that seems to be the point where your M1 fails. You need serial console cable and post clear text output where it fail. Still then, it might be too complicated to or time consuming fix. You could prepare/create/build a new own image using Armbian build. Or just stick to that older working image. It could be that the GUI drivers like it was in older kernels is dropped after 5.10 kernels or so, that happens to older hardware unfortunately. What is the kernel version where it still does work?

You know one can have multiple DE's installed and select which one to use at login? sudo tasksel kde-desktop lets you add KDE Plasma for every Debian based install. Important note is that RK3588 needs a pretty new mainline kernel otherwise forget KDE. With vendor kernel it should be no issue. So if you want to use KDE Plasma, no new image or install is needed. But maybe you only want to build an image and not use it.

Maybe have a look again: The NanoPi-R6S has 2x 2.5Gb eth and 1x 1Gb eth and soldered eMMC and a openWRT variant pre-installed. Can be ordered with all metal fanless case. I ordered the C variant as I wanted an M.2 M-key for my already Samsung 970plus 500GB NVMe SSD. Idle is about 1.5 Watt with Armbian vendor kernel but it runs various other distros as well with a Armbian rockchip64 kernel. As indicated, I use mine as a generic compact computing box currently, but I can imagin people use the S variant as router as is.

I did this: sed -i 's/buster/bookworm/g' armbian-image-release sed -i 's/21.05.1/25.2.3/g' armbian-image-release But I have motd stuff all muted as all is CLI/remote/ssh/unattended only. It is only for the case that in 1 or 2 years from now I don't get confused by 'buster' again. But I think this file gets orphaned for people doing in-place upgrades (not wiping SD with new image at least. I use it only to see when and how I got the new SBC and architecture/SoC running first time when not knowing much about a platform. For the 5 NanoPi-NEOs, they are all copied/cloned from just the first one I bought and got working and modified so it is a partition structure (Btrfs for root at least) that fits my regeneration-from-backup-NAS script for all Linux clients. After the clone action, the package tooling (and sources.list* contents) determine versions. What matters for me is MACaddress essentially (and some other keys and UUIDs). I only use os-release to see what distro flavor it is. And sometimes 'hostnamectl status' to see what is running.

On my NanoPi-NEOs I have seen this several times/years /etc# grep -d skip buster * armbian-distribution-status:buster=eos;upgrade=bullseye,bookworm,trixie,testing armbian-image-release:DISTRIBUTION_CODENAME=buster mime.types:application/rpki-ghostbusters gbr grep: motd: No such file or directory So I guess those files need some other text

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.