eselarm

From Bullseye to Bookworm Debian went from pulseaudio to pipewire. I spent a lot of time to remove/disable pipewire as the pipewire-pulse emulation was/is? not doing networked pulseaudio properly and I use that extensively. Opensuse Tumbleweed as rolling release does not have this issue, it keeps working. It also keeps working if you do in-place upgrade from Bullseye to Bookworm (what I normally do), but I started with fresh Armbian Bookworm downloaded image and can't get networked audio working (a must on a NanoPi-R6C with no audio HW). Now I would not be surprised at all if the combination of Armbian (Debian) Bookworm with added new KDE (beta) repo external to Debian introduces another complex issue w.r.t. audio, even locally. If Armbian (Ubuntu) Noble, then challenge is even bigger. I had too many Ubuntu issues, so went back to Debian. I have not tested 3.5mm audio when I tested KDE Neon image on my ROCK3A (ran it only for 15 minutes as planned use-case was/is headless server), but in a week I will get a ROCK5B and I will use that as Desktop for some time I guess. Plan is to just take the Samsung NVMe (10 partitions, multiple OSses) out of my NanoPi-R6C and basically only change .DTB loaded (i use extlinux.conf own scripted) and some U-Boot binary on otherwise blank SD-card and then bump that in-place to Testing/Trixie (using Btrfs snapshots as safety fallback). That has KDE Plasma 6.3 AFAIR from my tablet/laptop and it won't change much I guess (Tumbleweed is 6.3.4 currently). Then it is matter of using/checking alsa and/or pulseaudio and/or pipewire tooling what is going on. As indicated, existing pulse-servers (e.g. NanoPi-NEO with SPDIF to my amplifier) work and are found and can be selected via pulseaudio tray icon, including also local USB-audio on my N100 for example. So I personally would likely remove all external package repos and make it clean Armbian Trixie. If you want to contribute to KDE development, then keep KDE Neon I guess.

I always liked the Marvell ARM SoCs because of their many high-speed I/O, but never bought one as the main CPU(s) were always behind w.r.t. raw computing performance, compared to RPi4 BCM2711 or Intel J1900. Ebon Upton of RPL once stated they won't do SATA. Instead they made an own I/O chip and some own ISP silicon design for the RPi5. It is because the focus on digital signage, so computing devices with screens and cameras. For many home-users it means the struggle goes on. I only use my RPi4 with Samsung SSD for fast local I/O (VMs etc), but what a trouble with that whole VIA PCIe-USB3 chip design (you extra need external power in the end). And look at how many people still want to build a NAS with a Pi; So BCM271x-PCIe<=>PCIe_USB3chip<=cable=>USB3_SATAchip<=cable=>HDD(s)/SSD. Or some 'HAT' via yet another proprietary extra flatcable. And then not to forget the powering of such a setup, need 12V, RPi can only accept 5V. I think worlds big IT companies aim for cloud, central storage, your data, your privacy, so principles and methods to store your own data locally at home seem like a relative niche. Not that non-tech people don't know what NAS and backup etc is, but automatic cloud for laptops and smartphone is so easy. Then the other issue is that 4 or 6 or even 10 or 12 SATA ports mostly imply many 3.5inch HDD which need then 100W or so, so the 'low-power ARM' is irrelevant. And people seem to want RAID, many still think that is also good backup. What I also noticed as problem with older ARM SoCs it that for example the Marvell 88F6828 in Helios4 is 32-bit (dual Cortex-A9). Modern filesystems are more tailored for 64-bit native. For example, Btrfs does not support >8TiB in 32-bit, and because of its CoW fundamentals, it can also hit that limit with <8TiB after many years of usage (or lots of 'balancing'). So you want a 64-bit CPU/OS. I have a BananaPi M1 still, also same as Helios4 2x Cortex-A9, but only 1 SATA2 connector. I still like that board, it runs Armbian 6.12.x now and I use it to export raw /dev/sda (8TB Seagate SMR) via nbd-server as Linux block device. That works fine with 32-bit, the limit is mostly random I/O speed due to SMR and being a HDD. If I do LVM, LUKS, Btrfs (Zstd compression) remote on top of nbd-client on a NanoPi R6C RK3588s, it works without noticing the Gbit ethernet in between. If I replace the BananaPi M1 with a Radxa ROCK 3A (on-chip SATA), same behavior more or less, although It can also run the whole 'NAS' stack on its own RK3568. Only disadvantage is then that on-the-fly Zstd compression is a bottleneck. So that made me order a ROCK 5B (RK3588), that has comparable I/O connectors (M.2 M-key for NVMe, M.2 E-key for a SATA passthough connector). I also ordered a ASM1166 M.2 M-key, so I can have the same functionality as old power hungry Intel PC with 6-SATA for tests/fallback. Note that for my main 24/7 NAS (the ROCK 3A system now) I keep a limit of 8TB, that means I don't buy new bigger HDD and only 1 is enough. Caching is done with LVMcache on the NVMe. If HDD is not spinning, it is about 4.5 Watt.

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.