eselarm

Yes sure, else things are wrong. I removed those linux-dtb packages for my ROCK5B and NanoPi-R6C (both using EDK2 UEFIv1.1 RK3588) already quite some time ago. They use standard grub, no devicetree loading as the one provided in the EDK2 is new enough so all works for what I want with those 2 computers. I also removed it on other installations (ROCK3A, NanoPi-NEO) as those use extlinux bootscript so I can select various kernels and load the dtb just from /usr/lib

Looks great, but Allwinner A733 is 2x Cortex-A76 and 6x Cortex-A55 Maybe Claude should apologize.

Was this just there as a directory or was and is also package dtb-6.18.44-current-cix-p1 installed? If pure/only ACPI and not something with hybrid DeviceTree, this DTB package should not be there and you better remove it else next kernel update you will have the same issue. Also in latest Linux, the DTBs are in /usr/lib/modules/dtb/ anyway, so for some testing/merging U-Boot and standard PC UEFI firmware, I get them from there (is on a NanoPi-NEO, 32-bit ARM). There is likely a grub customization for Cix-P1 boards so DTB can be loaded, I saw the same for Radxa Q6A. On RPI4, I use UEFI in ACPI mode, so can use the standard method for Debian (or other distro) as on PC's. If ACPI implementation is not good enough for your use-case, then maybe have a closer look at it as I can imagine that you might want to keep the option to boot in DeviceTree mode some time in the future maybe.

Are you aware that 1 version of the Cix P1 bootloader/firmware is just crippled in such a way that it got a certification? Other versions of bootloader/firmware might expose more via ACPI and/or DeviceTree, so sort of hybrid. I only know that from BCM2711 and RK3588 EDK2 UEFI what you would get as potential options then (several then). Also one can select vendor or mainline for RK3588. No clue what is possible for Cix P1. But I see many potential options. For RK3588 (and other SoC's) also U-Boot in EFI mode can boot UEFI images, but it seems not a complete spec implementation also depends on what the kernel 'knows' form the specific SoC/platform (what is enabled in .config). I think you should determine for yourself what the computer shall do and based on that, make a selection on what you apply and run to the computer, so everything that is programmable or even HW. Like if for example audio would be very important for you, you might want to add a good quality USB audio stick instead of waiting for on-board audio drivers to mature or something via a speaker in a HDMI monitor.

Yes my worry with your setup is that there are potentially 3 tools dealing with the network: ifupdown, netplan, NetworkManager Netplan does configs for NetworkManager (and systemd-networkd) via yaml files but is not aware of old/legacy ifupdown maybe. And it seem Proxmox want to cover a wider range of releases and maybe distros, so it seems it does its thing via ifupdown2. I think you should simplify things w.r.t. networking, else you risk off-line situations for your RPi5 and including the VMs on it. I used also pihole and router as VM, I had once an issue with networking, and it gets very nasty and a small disaster if I cannot get things up and running again. So I have a serial USB-TTL cable connected to my RPi4 now, so that with a laptop directly connected to it, I am able to fix networking on the CLI, only by using nmcli. In your case, I would see if Proxmox can do things the strictly/native Debian Trixie way, so maybe do a test and tryrun: apt purge --autoremove ifupdown2 netplan.io If that looks like the whole thing would not work anymore, cancel. But as I indicated, I did this command and networking still isall OK. But no Proxmox, I use virt-manager or also directly edit config (.xml) files for VMs as well.

I see on my NanoPi-R6C, which runs Armbian Trixie userspace: # apt list | grep ifupdown ifupdown-extra/unstable,stable 0.34 all ifupdown-multi/unstable,stable 1.0.0 all ifupdown-ng-compat/stable 0.12.1-7 all ifupdown-ng/stable 0.12.1-7 arm64 ifupdown2/unstable,stable 3.0.0-1.3 all ifupdown/stable,now 0.8.44+deb13u1 arm64 [installed,automatic] From raspbian/debian Bookworm from RPL I know package ifupdown is not installed/included. Their Trixie is forced netplan.io as well, but if vanilla Debian, ifupdown is not needed if you just use NetworkManager to do networking. I have used in-place dist-upgrades for many years, so for most Debian systems I already purged the ifupdown package or went to systemd-networkd for more headless/unattended. At least NM only is perfectly fine for having a bridge with enslaved physical ethernet ports so that you can run KVM/libvirtd/QEMU with fixed (or spoofed) known HW MAC address so you can even have the installed Linux from old (broken) computer/SBC easily as VM and keep whole LAN or VLAN etc the same. I do not know what ifupdown2 is. Maybe it is due to netplan.io that is also used in Armbian Trixie fresh images. Only thing from this topic I currently see is that I need to cleanup that originally Armbian Bookworm on the my NanoPi-R6C so that it does not have/use ifupdown package, same as I already have done on an RPI4 that runs various VMs. I don't know why/if Proxmox maybe needs ifupdown2, I just use standard distro KVM/libvirtd/QEMU for years already on Aarch64 boards and works good/flexible enough for me. Proxmox also uses same KVM/libvirtd/QEMU underneath so I guess could be treated the same as a virt-manager/virsh operated system. NM also has it own internal ifupdown AFAIR, see its config for more info, I haven't touched it myself.

OK, so as I understand it now /lib/systemd/system/helios4-wol.service is not yours, but part of Armbian for Helios4. I already wondered why you did not put it in /etc/systemd/system/ Also then this is more a comment towards the Helios4 maintainer or in general the Armbian project/distro. In order to reduce maintenance effort, it might make sense to use just Linux generic methods. Even older 32-bit SBC's can use a lot like it is done in PC's, assuming it is latest Debian/Ubuntu or any other .rpm distro. Also the Helios4 I think is one of the few armhf systems that have implemented HW/wiring more like as it used to be for decades in PC's. I am currently doing a bit of alignment and cleanup my local/personal scripts, mainly with the objective of getting better power and energy handling. I have used rtcwake in the past so the computer can wake-up when no WOL support, but that is actually only 1 Acer computer I bought in 2007 or so, newer support WOL Using rtcwake is fixed time and also must be within a month timeframe AFAIR. WOL is much more preferred. Trixie has: # apt list systemd systemd/stable,now 257.13-1~deb13u1 armhf [installed] and I see in 'man systemctl' that the sleep command is added in version 256. I use(d) /sbin/poweroff or systemctl suspend. The latter via ssh for a laptop connected via either RJ45 or WiFi. The wake up is then just pressing the power button when I want to use the laptop again and are physically in front of it. For my ROCK3A (1 8T HDD connected) I know idle power consumption is quite low and it also does not support suspend nor WOL, so I just use hd-idle to save power.

@FredK I wonder now that WOL works from kernel perspective, do you need this script with ethtool to enable WOL? AFAIK none of my ARM based computers can use WOL as simply the hardware/wiring is not implemented, but for various Intel/AMD boards and using NetworkManager, it is something like: sudo nmcli connection modify "<connection-name>" 802-3-ethernet.wake-on-lan magic and then it works. In the connection-name profile file you will see then a section: [ethernet] wake-on-lan=64 When Debian (and no netplan.io) you can also edit the .nmconnection file and then reload.

Most important is to realize that it is Debian Linux, so in general at debian.org or various linux info sites should be your guideline. It takes time but step by step you get to know more and will be able to solve potential issues on your own. As you can see from Armbian docs: https://docs.armbian.com/User-Guide_FAQ/#can-i-upgrade-to-a-new-armbian-release it also suggest to look at generic Linux info sources and help on the longer term. So I would say https://wiki.debian.org/ But many other sources of info about Linux, maybe YouTube is more of interest for you. But it depends what you want with the Nanopi-NEO. Various people keep the base release for years (so Trixie (13) currently). Debian will keep packages from older releases, but not forever. So Trixie is now 'stable', will then turn to 'oldstable' mid 2027 and then to oldoldstable mid 2029. After that you won't see updates, so by then you might want to have learned yourself how to upgrade from 13->14->15 etc. Most important is that you make sure you learn yourself how to backup and restore your running installation. Then you don't need to download a new image in case for example your SD-card gets broken. There are several SD-card backup programs, throughout the years I made something myself in some scripts, but it is similar to 'btrbk', which is standard available in Debian. It allows to back-up whole computers while they keep running, so in case of my NanoPi-NEO's, I can keep the SD-card inserted as well. But of course a basic method is to take out SD-card, make a backup image of it or maybe copy the whole SD-card to a spare SD-card. But others sure have better tips as I don't use that method.

Nanopi-NEO is community maintained only, so it basically means that you need to maintain it yourself as you are writing some messages here you can consider yourself part of the community. So quite some DIY, but I have 5 Nanopi-NEO's 3 running 24/7 and all fine Armbian Trixie (with a bit of my own preferences and tweaks), but the core things (u-boot and sunxi kernel) work as expected and reliable and nice low-power. 1 runs a bit more experimental kernel 7.0.12-edge-sunxi, but already up for 23 days as USB-camera server. Another managing electric fence: root@nanopineo:~# uname -a Linux nanopineo 6.18.35-current-sunxi #1 SMP Tue Jun 9 10:28:53 UTC 2026 armv7l GNU/Linux So you can take the image listed on: https://armbian.com/boards/nanopineo and then do regular apt update && apt full-upgrade and every 2 year a dist-upgrade, (see Debian docs how that is done), I have done that since summer 2021 or so. There is indeed no LTS image, you yourself need to do the 'Long Term Support' with the help of everyone else who also wants to keep this nice and tiny SBC running for as many years as possible.

Yes indeed it is written there, So I might have mixed-up the defaults for other distros. The test I did in a container does not work with ssh because it uses the kernel and IP address of the host that has already occupied port 22 for sshd.

This is disabled by default since many years in Linux distros. You need a public key for that usually or manually change sshd config yourself. If you want ssh login at or after fist boot without first logging in via (serial) console, you can use this: https://docs.armbian.com/User-Guide_Autoconfig/ If I search in an exiting/running Armbian installation: # find / -xdev -name "*first*login*" /etc/profile.d/armbian-check-first-login.sh /etc/profile.d/armbian-check-first-login-reboot.sh /usr/lib/armbian/armbian-firstlogin I see from the latter script that if file: /root/.not_logged_in_yet exists, the fiirst login procedure should be run. I just tested this in a cloned temporary container and it works. It saves you from re-writing the whole SD-card again I would say. So as root at the (serial) console: # touch /root/.not_logged_in_yet # reboot

That seems to me the same as 'file-server' I mentioned; I do that on a RPI3 vanilla Debian Trixie (since Bullseye already), that all works fine. Only issue maybe is Broadcom firmware for the WiFi of the 02W, but if non-networked, then no issue. Also if non-networked, you cannot easily apply Btrfs method I mentioned via network, but still works if you take out SD-card and apply diff on another computer. Or via USB stick with the diff (a compressed Btrfs v2 stream as 1 file). I have done it like that as well more than a decade ago to sync large HDD's between 2 countries 1000km distance and old 1Mbps DSL internet so driving bay car is faster than transfer via internet.

Is this the whole SPI/MTD ? Why only 4MiB? My ROCK5B has a 16MiB SPI-flash and I simply wipe all. As I have seen methods to put GPT table in SPI as well, so what happens when and orphan different 2nd/backup table is still there and 1st is different/new or MBR based? Same of eMMC And why flash both SD-card and eMMC ? I would saw wipe all HW that is OPi5 and only use SD-card. It might be that Armbian uses a new DDR RAM init code in the bootloader that does not work on your specific OPi5 board revision, so to see what works, you need to post bootloader log (from the working one) as already said. So then people can see what the differences might be.

Why don't you take a closer look at apt sources and repositories and just tune those exactly to your needs? I am not an Ubuntu user anymore, but I remember they have a command/script/tool to get from 1 major release to the next. Should not be magic to do something manual to sources.list* so you have a .10 halfyear versioning. In addition, you can use apt pinning, so further fine tuning. Note that Armbian does not provide (vanilla) upstream Linux kernel for RPi boards, same for Ubuntu and various other distros I am aware of. Some do, via U-Boot-EFI loader layer. Also the RPi downstream is different from Armbian and also again Ubuntu's (-raspi suffix) is different. So my experience is that that is a major issue, but really depends on what the board should do. My recent check/test for just a camera streaming use-case failed, so only RPi kernel works (and bootcode.bin,start.elf,fixup.dat or EEPROM contents that come with that certain version). On the other hand, for a file-server or so, you can use whatever kernel, so for sure Debian's generic arm64 (trixie) work but also sid's one. You need changes in config.txt, especially for RPi 3-series also other DTB names are used and you might not want to use the latest bootcode.bin,start.elf,fixup.dat. See explicitly the version and contents of package: raspi-firmware (is different for the various distro's although same name) TI SoC/boards I have no clue, but if U-Boot, so also that is open-source, it should be a lot more flexible to have a certain repo as half-year base. At least forget about 'images' principle. Those 4-core C-A53 boards can easily use Btrfs for rootfs, so with subvolumes/snapshots, they can be easily upgraded while keeping them running and also old versions still there for rollback. I even do that on RPi0/1. As bonus is that Btrfs with its send|receive and parent-child differential subvols/snapshots, allows updating the whole rootfs (a certain subvolume snapshot) on another fast computer like Linux on Apple M1 or some RK3588 SBC with NVME as container and when done, send the diff back, change default subvolume, then reboot and done.

So it it this one: https://tinker-board.asus.com/series/tinker-board-s.html In the log I see 'USB Audio', also HDMI audio and there is a 3.5mm jack. I am not sure what audio and what the goal is. HDMI audio on Rockchips can be tricky, I have seen simulator kernel problem messages, depends also on which bootloader. Then I am not sure if on-board eMMC plays a role or not. The SD-card mmc0 is properly initialized but there is also mmc1 and mmc2 Can you post output of sudo lsblk And if eMMC is there, there might be old U-Boot there. Further there is quite some repeated registerdumps, that is not a good sign, but don't really understand why that happens.

I was curios and see on https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md HDMI high color depth support (6.19-rc1): PATCHv3 Haven't read more, but it is a patch, not merged (yet) in mainline tree. Applies to all RK3588 based platforms, like my NanoPi-R6C, sometimes start it with different/own kernel build, but not done any local patches. There is also LibreELEC, it has various (floating around) patches applied to mainline AFAIR. But Armbian is not a dedicated videoplayer platform, so depends on what you want.

and do the same thing for the SPI flash of the OPi5 if it has one, I don't remenber all 100's of boards. If old u-boot in SPI and new on SD-card then indeed it won't work. then wipe the SPI so the one from SD-card is used.

yes use strings command on the first 16MiB of SD-card or image and grep for text U-Boot

Also nothing on UART serial console?

You need a build computer, as I said read docs. If you only want to change .dtb, decompile it, change the .dts text, then recompile. see 'man dtc'

You should use Armbian Build to (re)produce images. That is what Armbian is about. Read docs. You will have sources all pulled from github on your local computer. It is even listed noadays per board https://armbian.com/boards/firefly-rk3399

I had a look what this brand/board is about and it seems the community has only 1 variant in the build database and pre-installed images only mainline kernel based. So I think you already digged quite deep into it and at the point that you are more expert than what is available. So it would mean you add the board to Armbian as also a community member and since it is mainline, it would mean just adding it to mainline Linux kernel, see Armbian docs how to add a board. For reference, latest kernel is here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip So upstream linux instead of downstream rockchip what is here: https://github.com/armbian/linux-rockchip/tree/rk-6.1-rkr5.1/arch/arm64/boot/dts/rockchip or to some other repo (Firefly, vendor?) Where you got that rk3399-roc-plus.dts from? But more important: is just very little info. What went wrong? You need UART serial console/debug cable output shared here and also how did you clone and compile? e.g. what .config is used, etc. If I would have this board, I certainly cannot reproduce your issues or compare potential non-booting symptoms with yours, so try to provide all that it needed so someone else can do and see then same as you.

This board is community maintained only, and there is a tag for, so it should have been posted there. You cannot assume now already that is SD-card or PSU issue. Much more info is needed. Starting kernel... is what you see on a HDMI screen. Probably more happens, but to show that, you need to set: verbosity=7 in the file armbianEnv.txt Then still might not be enough to diagnose, so you would need to connect UART serial console cable as then you will see everything from power on. That is usually needed, else it is guessing and no-one will waste time on that.