SteeMan

Moved to the correct forum (community support). This is not a supported board. Adjusted the tag to reflect the correct board.

Change title to reflect the real question and moved to the appropriate forum

But the answer to your followup question is: config/sources/families/include/sunxi64_common.inc

Why did you title this thread Raspbian if this isn't about a rpi4 or rpi5 device? Maybe you need to explain a bit more about what you are trying to do. The Armbian builds for RPI devices pretty much use the standard raspbian sources. But the sunxi builds have like a hundred patches applied and that is a lot of work to port all those patches.

If you are pulling the armbian build framework from git and following the armbian build instructions, then.. The file you would want to change would be: ./config/sources/families/bcm2711.conf (adjust the appropriate section 'current' or 'edge' for the specific version you are looking to build) But note then you would also need to port the armbian patches for that kernel version, unless you are OK without having the armbian patches applied to your kernel. The armbian patches are located: ./patch/kernel/archive/bcm2711*

moved post to correct forum

The short answer is from your first post in this thread: These are mostly community supported boards. So it is up to volunteers in the community to add and test features, even ones like this that you consider basic. However, I think I would add the following comment. Based on another comment you made in the first post: That statement I think would have been correct probably 5 years ago. Today, not as much. I would venture to say that today with the latest generation of CPUs that most users are looking to SBCs as desktop replacement devices. So features like video acceleration, etc. are what we see the most requests for. So features like these basic lower level SPI/I2C etc get pushed down the priority list for those that are volunteering their time (unless they have that particular need themselves).

https://docs.armbian.com/Process_Contribute

@BladeCoder The official way to switch kernel versions is via armbian-config

It depends on which repository you are pointing to. But in general if you are pointing to the stable repository (apt.armbian.com) then you would see releases as they flow out to the stable channel. If you are pointing to the nightly rolling release repository (beta.armbian.com) then you get nightly rolling release builds. (look at what repository you are using in /etc/apt/sources.list.d/armbian.list) The version you are reporting for armbian-config is a nightly version (25.2.-trunk is a rolling release).

multiboot means different things in different contexts. But in this context it is the process that is used for amlogic based tv boxes to get the native Android uboot on the emmc to boot armbian from SD card. The process is to press the reset button with the SD card inserted which causes the native uboot to look for a certain file on the SD card which is then read and adjusts the uboot environment so that future boots will first boot from the SD card.

Don't know, as I am fine with using the IP address so never researched further. I suspect it is a timing issue between DNS starting and wireguard starting.

This is likely the error you are running into. Is that your valid domain name for your wireguard server? I have had issues with wireguard starting before DNS name resolution is in place which I resolved by using IP addresses in the wireguard config files instead of domain names.

Have you tried what I suggested to you previously? https://forum.armbian.com/topic/27210-how-to-install-armbian-to-amlogic-s805-android-box/#findComment-163422

So according to your last comment you are using a custom dtb file. You do know that installing a new kernel version deletes the entire dtb directory and replaces it with what is shipped with that kernel version? So if you have a custom dtb it may be the issue that it is being removed during the upgrade. You need to put a custom dtb file in a location not under /boot/dtb. I don't know if this is your issue or not, but I thought of that based on the information in your last post. Another suggestion, is to put a current image on an SD card and see that that boots. That way you can determine if the issue is with the current code, or something that is happening during the apt upgrade.