SteeMan

You should also be updating your /etc/apt/sources.list.d/armbian.list as well (otherwise you will be mixing bookworm armbian packages with trixie debian packages)

Look at your board config file:  config/boards/orangepi5b.csc
In there you will find the board family, which in your case is:
BOARDFAMILY="rockchip-rk3588"
 
Then look at the corresponding board family config file:
config/sources/families/rockchip-rk3588.conf
 
There you will find a section for each branch (i.e vendor, current, edge) that will specify which kernel source is used:
For BRANCH=vendor that would currently be:
        KERNELSOURCE='https://github.com/armbian/linux-rockchip.git'
        KERNELBRANCH='branch:rk-6.1-rkr5.1'
        KERNELPATCHDIR='rk35xx-vendor-6.1'
 
 
 
 

I'll provide some background on what you are experiencing.
6.1 is the vendor kernel.  This is what comes from rockchip and is a hacked together set of code that they release to board builders.  Armbian doesn't have really any interest in maintaining this code base.  6.12 is mainline Linux directly from kernel.org with some additional.patches applied.  It often tales years for the open source community to get new CPU variants incorporated into the mainline kernel code base, as the vendors (rockchip and OrangePi in this case) don't generally contribute.
So 6.12 is actually far behind in feature support for your board.  The edge kernel, 6
16 would be better.  But if you want a feature complete kernel.for your board, the 6.1 vendor kernel is best.  If you want security updates but can deal with lack of some features, then the edge kernel should be your choice (at least until early next year when Armbian current moves to the next Linux LTS release).
 
Also, from the perspective of best boards under Armbian, you probably are better off with Armbian supported boards, not a community supported board which by definition doesn't have anyone maintaining it.
 
Final note, is that Orange Pi as a company does nothing to support the open source community.  I'd say their main goal is to pump out new hardware as fast as possible and not supporting older hardware in any way to force people to spend more money with them. In general support and software is a huge cost and doesn't provide any profit for them, so they choose not to provide it.

I'll provide some background on what you are experiencing.
6.1 is the vendor kernel.  This is what comes from rockchip and is a hacked together set of code that they release to board builders.  Armbian doesn't have really any interest in maintaining this code base.  6.12 is mainline Linux directly from kernel.org with some additional.patches applied.  It often tales years for the open source community to get new CPU variants incorporated into the mainline kernel code base, as the vendors (rockchip and OrangePi in this case) don't generally contribute.
So 6.12 is actually far behind in feature support for your board.  The edge kernel, 6
16 would be better.  But if you want a feature complete kernel.for your board, the 6.1 vendor kernel is best.  If you want security updates but can deal with lack of some features, then the edge kernel should be your choice (at least until early next year when Armbian current moves to the next Linux LTS release).
 
Also, from the perspective of best boards under Armbian, you probably are better off with Armbian supported boards, not a community supported board which by definition doesn't have anyone maintaining it.
 
Final note, is that Orange Pi as a company does nothing to support the open source community.  I'd say their main goal is to pump out new hardware as fast as possible and not supporting older hardware in any way to force people to spend more money with them. In general support and software is a huge cost and doesn't provide any profit for them, so they choose not to provide it.

This isn't completely true.  Armbian still does utilize CPUMIN/CPUMAX from /etc/default/cpufrequtils if present to set corresponding frequencies via the Armbian script armbian-hardware-optimization (packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization).  This script I believe runs at every system startup.  So even without the cpufrequitls package installed, there is still some functionality in this area.  Functionally that no one has likely touched or looked at in years.
 
 
 
 

Please do not promote forks of Armbian on these forums.  If you what to help Armbian, please submit PRs and contribute code that makes Armbian better.  It doesn't help to have yet another fork of stuff out there that never gets contributed back.
 
Your warning about using external builds applies equally well to external git sources.  No one should trust this unless they inspect all the changes you have made from genuine Armbian.  User be warned.

Moved to Community support area and adjusted tag for proper board identification

A google search indicates that the MXQ Pro 4K 5G often uses a RK3229 quad-core CPU

There are probably 20 different CPUs that have cortex a53 (cpus from Allwinner, Rockchip and Amlogic).  TV box manufacturers all the time will use different CPUs in TV boxes that have the same external markings.  Which ever component is the cheapest at the time of manufacture is what gets used.  The only way to really be sure what you have is to look at the chip on the board (but even then there are cases where chip markings have been altered to make you think you have something else).  Welcome to the world of TV boxes (and why Armbian doesn't support them officially because they are a mess).

I just want to add a few comments to this whole dtb overlay discussion.
 
First I want to thank all of you involved in this discussion.  You all have different view points and I think are tackling a very difficult problem to which there is no perfect solution.  What comes out of this discussion should be applied to the other soc families as well, as they all suffer from some form of this issue as there is no standard in place that works for all use cases well.  From what I have seen, good minds are thinking this through and I expect a good result to follow.
 
The reason I am commenting at all, is because in my role as forum moderator, the basic question: "How do I enable feature x on my board" is one of, if not the most commonly asked question by end users of the forum.  And when the answer is 'just write a dtb overlay', you have lost 95% of those users as they do not have the skills/knowledge to do that.  The status of the dtb overlay's across Armbian supported and community maintained boards is poor.  There is no standardization from family to family or board to board.  And no testing of what does exist to ensure that it works.  Now I'm not saying that all of this needs to be solved in what comes out of this design discussion.  I'm just saying from my perspective as a moderator that this is an area that can use some attention, and in doing so, please try to make the end result usable by the typical end user of an sbc, trying to do common things.  I realize also that I'm saying this when I only use these boards as servers and don't personally need any of the functionality the overlays provide.  But as a forum moderator, I see the mismatch between what is being done and some common use cases that end users are looking for.

Have you tried the generic rk3328 builds found discussed in this thread: 
 
 
I would start there by reading that thread.  Your box likely has a lot in common with what is discussed there.

Of course you are free to try Armbian images, but you should know that the Orange PI 3b is not an Armbian supported board.  It is community support status and there is no maintainer who has volunteered to maintain it.  I just want you to understand and set your expectations appropriately for what an Armbian build will provide you.

I think your real question is why hasn't Rockchip put in the effort to get these drivers into mainline linux?  It isn't the goal of Armbian to be the repository of large amounts of unmaintained code.  The goal is really to bring mainline linux to devices.  But that assumes that everyone else is working to bring various bits and pieces from custom linux forks to mainline linux.  While sometimes it is necessary to temporarily host code that has been ported to mainline, but not yet incorporated upstream, most of the efforts should be to get the code into upstream mainline linux.
 

You will have to uninstall the upstream wireguard as that will remove the dependancy on the non-armbian kernel.

Not right at all.  Every SBC that has different hardware configuration requires a different dtb file that describes the hardware to the Linux kernel.  So every SBC needs it's own build ( sometimes dtb overlays can be used to shortcut this).  And similar issues can exist at the uboot level too.  

Generally debugging is done through the UART connector: https://debug.armbian.de/

Whenever you are comfortable with that.
You could brick your box.  Unlikely, but there are so many different tv boxes out there that there is always a chance your box is somehow different than common ones.  Since the boot environment starts from what is on emmc, if you screw up the emmc completely, your box is bricked.  (You should still be able to recover by using amlogic tools to reinstall an android rom, but...)
No limit that I can think of.
You have that all correct.

While normally we discourage references to ophub as they are a fork of Armbian  but continue to use the Armbian name without permission for their fork.  They also don't contribute back to Armbian nor do they participate in these forums, I think your post is helpful.  It would really be nice if someone were to dig into this and submit a PR back to Armbian to bring the support into the base code that is maintained here.

that should be 1500000 (one more zero).  Note a lot of uart connectors can't handle this high of a speed.  There are many threads in the forums discussing specific ones that are able to reach that speed.

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
 

As long as the board isn't dead it is starting to boot.  That is why Werner directed you to how to capture the uboot booting messages via a uart connection to the board.

https://docs.armbian.com/Developer-Guide_Build-Commands
If I read your post correctly, I think you want ./compile.sh kernel ...
which will build the kernel debs but not the full image

I think this line is wrong.  I don't believe that the overlay_prefix should be included here, try with
overlays=i2c1-pi
I seem to recall mention of a bug in armbian-config that was doing the wrong thing regarding overlay_prefix when selecting overlays.

Closing this.  This isn't going anywhere good.  Both sides have made their points.

These instructions are for Amlogic CPUs for TV Boxes. 
 
Note: If you have previously run other distributions on the box such as coreelec the below installation will not work.  You will need to restore the original android firmware before attempting the install.  coreelec changes the boot environment in ways that are incompatible with these Armbian builds.
 
Download links:
    Weekly Community Rolling Builds:  https://www.armbian.com/amlogic-s9xx-tv-box/
    or build your own image using the Armbian build framework
 
Once you download your chosen build, you need to burn the image to an SD card.  Generally balenaEtcher is recommended as it does a verification of the burn.  Also be sure to use high quality SD cards.
 
Once you have the SD card with your chosen build, then you need to edit the boot configuration file on the SD card.  In the BOOT partition of the SD card there will be a file /boot/extlinux/extlinux.conf, that you need to edit.  There will also be a extlinux.conf.template file to use as a reference.  You will need to add a line into the extlinux.conf file for the Device Tree (dtb) file you will be using for your box.  Place this line before the APPEND line as shown in the .template file.
 
Basically you need to have the correct dtb for your box.  You may need to attempt to use different dtb files until you find the one that works the best for your box's hardware (there are a bunch of dtb files in /boot/dtb/amlogic/... to try depending on your cpu architecture and hardware).  It is unlikely that there will be a matching dtb file for your TV box.  The idea is to find the one that works best for your box.  This may mean that you try booting with different dtb files until you fine one that works good enough for your needs.  By searching the forums you will find information about what dtbs other users have found work best for different boxes.  Because you are booting from an SD card, you can easily try different dtb files.  The dtd files are named by cpu family.  So for example dtb files for the s905x2 cpu are named meson-g12a-*.  Below there is a table that shows the identifiers for each familiy (g12a for s905x2 in this case).
 
Next you need to copy the correct uboot for your box.  This is needed for how these builds boot on amlogic boxes.  There are four different u-boot files located in the /boot directory:  u-boot-s905, u-boot-s905x-s912, u-boot-s905x2-s922, u-boot-s905x3
You need to copy (note copy not move) the u-boot file that matches your cpu to a new file named u-boot.ext in the /boot directory
So for example with a TX3 mini box that has an s905w cpu you would copy u-boot-s905x-s912 to u-boot.ext: cp u-boot-s905x-s912 u-boot.ext
(See table below for more details on which u-boot to use for which cpu)
 
Once you have your SD card prepared you need to enable multiboot on the box.  There are different ways documented to do this, but the most common is the "toothpick" method.  The "toothpick" method means to hold the reset button while applying power to the box.  The reset button is often hidden and located at the back of the audio/video jack connector.  By pressing that button with a toothpick or other such pointed device you can enable multiboot.  What you need to do is have the box unplugged, have your prepared sd card inserted, then press and hold the button while inserting the power connector.  Then after a bit of time you can release the button.  (I don't know exactly how long you need to hold the button after power is applied, but if it doesn't work the first time try again holding for longer or shorter times).
 
You should now be booting into armbian/linux.  Note that the first boot takes longer as it is enlarging the root filesystem to utilize the entire SD card.
 
After you are satisfied that your box is working correctly for your needs you can optionally copy the installation from the SD card to internal emmc storage (assuming your box has emmc). (Note: Installing to emmc has some risks of bricking your box.  Don't do this unless you feel you understand how to reinstall your box's android firmware)  You install armbian to emmc by running the shell script in the /root directory: install-aml.sh. Note: It is not possible to install into emmc on boxes with the s905 cpu (s905x, s905w, s905x2, etc however should all be supported).  It is recommended that you make a backup of emmc first.  Also be prepared if anything goes horribly wrong with your emmc install to reinstall the android firmware using the Amlogic USB Burning Tool to unbrick your device.  If you have or can find an original android firmware on the internet and you can generally (but not always) recover a bricked box using the Amlogic tool and the original firmware file.
 
 
Mapping from CPU to uboot and dtb:
 
u-boot-s905
s905 - gxbb
 
u-boot-s905x2-s912
S905X - gxl
S905W - gxl
S905D - gxl
S905L - gxl
S805X - gxl
S912 - gxm
A311D - gxm
 
u-boot-s905x2-s922
S905X2 - g12a
S922 - g12b
 
u-boot-s905x3
S905X3 - sm1
 
Not supported or not tested
S805 -
S905W2 -
S905X4 -
S805X2 - s4
A113D - axg
A113X - axg
 
 
 
Note: Followup posts in this thread should be limited to comments to improve or better understand these instructions.  Other issues should be posted as new questions in the Amlogic CPU Boxes sub-forum.