SteeMan

Welcome to the world of Armbian on TV Boxes!
 
TV Boxes are not officially supported by the Armbian project.  This "TV Box" sub forum is for users interested in experimenting with Armbian on TV Boxes.
 
Overall you will be best served if you set your expectations low as to what you might be able to accomplish with your TV Box and Armbian.  Specifically you should think of your TV Box as a potential linux server - *not* as a desktop replacement.
 
Feel free to post and ask questions in the TV Box forums if you are interested.  But realize this is a peer-to-peer forum so you may or may not get an answer.  Don't expect or demand support as there are only a handful of people that participate in these forums and they are all donating their time.
 
Search is your friend.  There is a lot of historic information stored on this site.  Your question has likely already been asked previously.  However, a lot has changed over time and therefore be prepared for a lot of the information you find by searching the forums to be outdated and in some cases just plain wrong.  Even though that may be the case, please search the forums first before posting a question.  It shows you are willing to invest the time to do your part and makes those of us who volunteer our time to answering questions more likely to want to help you.
 
 
Amlogic (S9xx) based TV Boxes
1. There is a community build for Amlogic based s9xx TV Boxes - The key being community - so please contribute to make improvements
2. A single developer (@balbes150) had worked years on getting things to the state they are.
3. As of October 14th, 2020 balbes150 removed support for Amlogic CPUs, so that is the last active build from him
4. Expectations should be set low (i.e. don't expect anything to work) but if you do get the box to boot, get HDMI and wired ethernet to work, you are doing good.
5. You really shouldn't expect things like Wi-Fi, bluetooth, remote control, etc. to work.
6. There is a very small number of people on this forum/club that are able to provide any guidance.
7. Most likely no one on this forum owns your specific box and therefore generally can only provide vague guideance.
8. If you get this working on your box, it will likely only be useful for server type tasks, maybe a little light graphical desktop usage, but do not expect video playback, etc.
 
RockChip (rk3399, rk3328, rk3288, rk3228, etc) based TV Boxes
These are probably the best supported TV boxes currently.  They have the most active developers.  Feel free to post in the Rockchip TV Box sub forums your questions.
 
Allwinner (H6, H616, H313) based TV Boxes
There is no ongoing effort to support Allwinner based boxes.  Occasionally a developer will respond to a question, but in general if this is what you have, you will be expected to do a lot of work on your own, so you better be comfortable doing development for these type of boards.  You aren't likely to find anything that you can just install and have work.
 
Other Comments
The official recommendation from the Armbian project would be to not use TV Boxes and use officially supported SBCs. Taking this approach will likely result in an easier time, less hassle, better support and likely a more fully functioning device.
 
There are reasons you may choose to want to use unsupported Armbian on TV boxes, for example here are some of my ( @SteeMan ) reasons:
 
1) It is a challenge and therefore a learning opportunity.  I would never have learnt to build my own linux kernels from source if I was still exclusively using x86 hardware.  If you want a challenge you will find it here.
 
2) Price vs specs.  The Android TV boxes are built to be cheap consumer devices.  They are produced in larger quantities which drives down the per unit price.  You will generally not be able to get the same level of hardware for the same price with a standard SBC.  But that cheapness comes with - no support by the manufacturers and potentially sub-standard components.  If the manufacturers goal is to sell the lowest price box they are likely cutting corners somewhere to make that happen.
 
3) emmc is standard.  TV boxes always come with internal storage while most SBCs do not.  Again from a price/performance standpoint having internal emmc storage vs running off an SD card is a plus.  emmc storage *should* be faster and more durable than storage on an sd card.  The caveats here being that this is one of the areas that the manufacturers may cut corners.  For example I have two TX3 mini boxes that are supposed to have 16GB of emmc memory (like the other TX3 mini boxes I have), but they were instead manufactured with cheaper nand memory for which there is no mainline kernel support.  There is no visible difference between the identically packaged boxes that had emmc vs those that came with nand, other than opening the case and looking at the physical chips on the boards.
 
4) cases come standard.  TV boxes always come with cases, whereas for SBCs that is an extra cost.  For my uses having a case is a big improvement vs not having one.  A downside if that these cases are not necessarily well designed to provide adequate cooling.  So depending on your use case, overheating might be a problem.
 
5) While I own both SBCs and TV boxes, I personally find the TV boxes work best for my needs (running server based software) and I enjoy the challenge of getting them running and keeping them running with the great underlying work that the Armbian project is doing to build on top of.
 
If you have the correct expectations (set your expectations low) are looking to learn and are up for a challenge these are fun things to work with.  And I look forward to working with you on these forums.
 
 

@kingbecher  This is now off topic for this thread, but you need to look at: https://www.armbian.com/amlogic-s9xx-tv-box

@kingbecher Why do you believe this isn't  an Amlogic s905w?  Those cpus are also cortex-a53.  I see Amlogic references throughout the boot log you posted 

Duplicate
 
 

But it is that extra money that is paying for the better support after the sale that you see in the RaspPi ecosystem.  All the other SBC vendors compete on low price and can't afford to provide any support after the sale and rely on open source volunteers to provide their long term support.

moving to Amlogic TV Boxes as I believe (via a quick google search) that this is amlogic cpu based.

Moved to the correct sub-forum

moved

So you are saying that when you copy the working SD card install (by working I mean that it has the correct memory amount) to emmc that the problem occurs?

I don't think you understand how Armbian works.  This board is community supported.  It does not and hasn't been an Armbian supported board.  Given the hundreds of boards out there Armbian only has the resources to officially support a handful.  The rest end up being supported by the user community like this board.  Thus support is only as good as the community volunteers who have the board and wish to volunteer their time to support it.  Armbian provides the tools and infrastruction to make supporting boards easier, but the work still needs to be done by someone for community supported boards like this.

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.