usual user

I think I have to disappoint you, see here.

I have nothing to decide here, if you want it to be in Armbian you have to convince an Armbian maintainer to pick it up. I also use Armbian only very sporadically for board bring-up and initial tests. Nevertheless, when the release has taken place, I will build a uboot-tools package for me and can, if you wish, upload the firmware.
 
I use it to start my system from SD card or via USB connection. I don't see  any reason why it shouldn't work with eMMC, but you only know for sure if  you've tested it. For me it was the first action to replace Petitboot with  a mainline uboot.
You have to wait a little longer, see here.
Release v2022.07 has taken place and the uboot-tools package has been build. I am running the firmware from SPI flash and it is working flawless for me.
Since distro-boot is supported for free, the use of an extlinux.conf allows to select the current kernel, an previous one and a persistent one with the option to enable SPI flash for ODROID-N2 or ODROID-N2+. See the attached extlinux.conf as an example implementation.
More details can be extracted from this thread, with its distracting posts in between. It is possible to keep as many different kernels installed as persistent space is available. A kernel upgrade will never leave an unbootable system behind as long as a previously working one is still installed.
So if someone wants to experiment with u-boot-meson.bin, you have to let me know and I will upload the file.
extlinux.conf

The firmware (uboot) is loaded by the maskrom code in the safest and slowest mode to use only minimal eMMC requirements. When uboot takes over, an attempt  is made to switch to a more efficient mode. If this does not succeed, it can  lead to the observed behavior. Since I don't know if more recent uboot  versions have already fixed a possible problem, I had offered my v2022.07-rc2  build for a quick test. Unfortunately, in the other thread it looked like the maskrom code couldn't even read the firmware blobs and without console logs  it's not really to analyze. So if you want, try v2022.07-rc2 it's a simple:
dd bs=512 seek=1 conv=notrunc if=u-boot-meson.bin of=/dev/${entire-card-device-to-be-used} ; sync  

128MiB cma is probably not sufficient according to here:
 

The type of remote control does not matter as long as it operates near the 38kHz carrier frequency and a suitable rc_keymap.toml is loaded. The reason I used the RC-100 is because I'm using the SD card I originally set up for my NanoPC-T4, and there this remote was configured for rc-empty. Therefore, it worked out of the box.
Went on to 5.19.0-rc3. And with the Enable-JPEG-Encoder-on-RK3566-RK3568.patch, a JPEG encoder is also available (videoX-infos.log). MGLRU is also pulled in again but only to see if it does not cause regressions with Odroid M1.

@jock - little update: v12 of the patches is out - it is essentially v11 pus the above mentioned fixes and rebased for v5.19:
https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao@google.com/
https://patchwork.kernel.org/project/linux-mm/list/?series=650073
https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v12-For-Linux-5.19-rc
https://github.com/hexdump0815/kernel-extra-patches/tree/main/multi-gen-lru/v12
best wishes - hexdump

Ok, I went on to 5.19.0-rc1. I was able to skip a lot of mainline commits from tobetter's tree because they landed, and for the remaining WIP commits, I switched to more recent ones. Some of the WIP commits are already in staging and will land sooner or later.
For those who are interested, I have attached glmark2 logs. The performance is not yet overwhelming, only the basic functionalities have just landed. But the graphical desktop works pretty decently. So the fine-tuning season is open.
And with the hantro decoder wired up, hardware-accelerated video decoding of H.264 and VP8 works up to 1080p. See fluster-run.log for reference.
Went on to 5.19.0-rc2. And with the ir-receiver wired up, my RC-100 works out of the box.
Rant: Why doesn't editing allow spoilers to be created with sections of code?
glmark2-wayland-odroid-m1.logfluster-run.log

Ok here's a new version, 5.18-rc7 from tobetter's tree. Still very early days.
tobetter is doing a fantastic job this time around, keeping his tree rebased properly this time.
 
This version has working NVMe (!), panfrost somewhat works, some hangs when panfrost is used.
eMMC does NOT work in my experience, it hangs the machine if trying to use it. use SD card.
 
unzstd, burn to SD, boot either with or without holding the button. (it should NOT go into or through Petitboot either way, instead the SPL in SPI should find and boot uboot in the SD card, or with button boot all blobs from SD).
 
https://github.com/rpardini/armbian-release/releases/download/20220522c/Armbian_20220522c-rpardini_Odroidm1_jammy_edge_5.18.0.img.zst
 
(4.x stuff still does not have HDMI, I've no idea why, it's otherwise stable, but I won't post it here since most people just assume it does not work at all if HDMI does not work)

Now I would also like to dream:
When commissioning a new system, I imagine that I will be offered a menu at the first boot in which all configurations available for selection are displayed. Since the SBC can't read my mind, at least I hope so, I choose the one I want. The system then starts and performs its first boot routine. At the next start of the system I wish for a dedicated menu of my previously selected boot option.
 
I'll leave it up to you to explore what changes you think are necessary.
 
Nevertheless, let's see how I would approach the matter in my dream. First, I would create a numbered extlinux.conf for each configuration selection with the following naming scheme: extlinux.conf-xx  with xx=01, 02, ...
The initial extlinux.conf contains only the fail save boot options of the available configurations. In addition, I append a boot parameter of the following form to each append line: bootoption=xx with xx=01, 02, ...
Then I write a shell script that searches /proc/cmdline for bootoption= and then copies the corresponding extlinux.conf-xx to extlinux.conf depending on the value found. Now I make sure that the script is executed as part of the first boot routine, and my dream should come true.
Wait, do I have just developed a method how distro-boot can communicate to the running system which boot option for the successful boot has been used. Am I still dreaming now or is all this already really feasible?

Congratulations, now we are in business.
It uses exactly what is described in your quote (https://www.kernel.org/doc/Documentation/arm64/booting.txt). The kernel is build with the Image.gz target and the firmware (uboot) decompresses it. And, surprise, uboot can automatically detect at what kind of kernel the extelinux.conf kernel key points. I have so much more to elaborate about what has been achieved so far, but no time right now. So I have to put you off on a follow-up post, please stay tuned.

Please do not do this, it will prevent the usability of kernels installed at the same time.
In the end, we won't use anything in /boot.
 
Firmware (uboot) is the only device specific code and is dedicated to each SBC. Having it on the SD card prevents it usability for different devices. The best is if you can offload it in a SPI flash. There is not one uboot that suits everyone.

The task of my discussion was to define a uniform GPIO naming scheme for the 40-pin connector of different devices, so that if e.g. user space addresses "con1-07", it does not matter on which device it is executed. It will always access pin 7 of the 40 pin connector. The mapping is done in an one effort via a devicetree-overlay and you get portable user space tools. However, this must be done in a collaborative effort, as no one has access to all devices to create the collection of overlays. Users can then reuse tools written for a specific task regardless of the current device and have no mapping problems like e.g. with WiringPi.

I can now confirm that HDMI audio is up for me. I am still on my NanoPC-T4 MicroSD card but it was only necessary to insert appropriate Odroid-N2+ configurations.
 
I used the settings from here.

Damn, missed the rebase of the  "Draft: v4l2codecs: Implement VP9 v4l2 decoder" patches and the source branch has been deleted.
With gstreamer main branch as of 11.12.2021 I get this video-pipeline-vp9.pdf and everything is working as expected.
Just discovered how to gather some video playback statistics while playing online videos. I still don't know which backend is used, but since I can play e.g. three videos in parallel, I'm pretty sure the VPU will be used.
The eagle  has landed. \o/

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt

This demonstrates that you know very little about Armbian. Official support is granted for boards which have official specs and whose manufacturers provide datasheets. Hopefully those manufacturers also provide fundings, sponsorship or any kind of support. There is no reverse engineering with officially supported boards: manufacturers provide specs, in form of openly available electrical diagrams and general documentation.
 
Tv boxes don't provide any datasheet about board specs, often chinese manufacturers even provide fake specs to buyers to sell their crap. They definitely does not sponsor the project in any form, thus Armbian does not endorse any tv box, nor do I: you need something for a serious project? Buy serious hardware, not chinese cheap and unsupported crap.
 
If you think Armbian purpose is to tell you how to understand boards and their chips, understand datasheets, write proper device trees, configure and compile the linux kernel, and whatever it requires to properly support a board, you're out of context.
I spent time doing all of these things above, so everyone else can do that. If you don't have enough skills to do that, that's not a fault of the project. You can still build up those skills, if you have enough time and will to sacrifice for the purpose.
 
There is a donation and help providing page, not just money, but whatever people can do is appreciated, even writing documentation.
Plus the community does not need to be funded with money, it is funded by will of people who wants to do something useful for others.
 
Armbian is not a company that does things on people request and I don't think you can "hire" someone from inside the project for your particular needs.
But again I repeat: you can still contact and pay developers - ANY developer, not necessarily an Armbian developer - for your needs.

Sorry but I have to be sincere about this: I don't like the reasoning, I found it unethical.
 
Believe it or not, I don't receive any kind of money from anyone; Armbian team also does not receive anything from these no-name boards, instead has to pay electricity, bandwidth to host images and forums.
It is just courtesy of Armbian guys if all of this is possible, they ask nothing in charge; although Armbian does not officially support any TV Box - as clearly and boldly stated in the first posts of all my threads.
 
My role in all of this is just driven by passion and learning, not money. I decided to share my work and studies with others because I think that if other people does the same, the world will become a better and funnier place.
As you see, the learning curve is pretty steep, and trying to build an out-of-the-box working solution for boards whose specifications and datasheets are kept secret is a huge time wasting job.
What I expect in change is usually a "Thank you": most of the time it suffices.
 
Here I read, and I really hope I misunderstood the post, that someone is going to make business around this.
That's pretty ok to me: I do support tv boxes for passion. I also use Linux which is free and made by others for passion and work and I pay nothing to anyone; nonetheless I contribute to opensource the way I can.
 
Now if your concern is missed support, don't ask community what can do for you and point out what community is not doing for your business; start thinking about what you can do for community that helps both community and your business.
In all of this long thread I don't know how many people donated to Armbian project - I'm not part of the official team.
But I'm totally sure that, except for the very generous board donations from @fabiobassa to whom all people here should as well be very grateful, I never ever received a penny or one board from anyone. And note that I don't ask boards as gratification - I already have several of them taking dust - but to study them. Nonetheless I am still here available for free support and for fun.
 
Asking me, or anyone else, to spend money to buy cheap crap and spend time reverse engineering that crap for your business is just unethical. It's parasitizing.
You need good Linux support for your tv boxes? Ask the manufacturers of those boxes, and see what they answer to you.
The problem about the "right price" is that the price can't be right if you don't include software developing and maintaining costs. Chinese tv boxes manufacturers are fetching "just working" Android distro into their products. If they would want to support a full linux environment, the price would be three or four times the actual price.
 
Want to talk about business?
Send a precise request to the developer of your choice (me included) and wait for a proper price quotation.
 
Want to do everything by yourself? You can.
Armbian developers spent hours to write proper documentation, available on docs.armbian.com. Source code is publicly available on github repository.
If you find it difficult navigate into, spend hundreds of hours lo learn things, as me and several others did, to raise your skills to keep up with your business.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt
 
https://source.denx.de/u-boot/u-boot/-/blob/master/doc/README.distro

I don't know what requirements Kivy places on the graphics stack, but since Panfrost achieves OpenGL ES 3.1 conformance on Mali-G52, it certainly makes sense to read this to understand what to expect from a lima-driven GPU. I still remember very well times when my GPU only reached almost 2.0 and the performance was quite moderate. With now 3.1 it's a big difference for daily desktop use, although my GPU isn't yet declared fully compliant. But since this is bleeding edge development, at least the current mesa mainline release is required in any case. If not even the main branch to use just implemented extentions. Kernel driver wise everything necessary should already be available and therefor mesa is where you are looking for GPU support improvements.

Then why not start, @jock has announced new versions and the links on the first page are already up?

Then why not start, @jock has announced new versions and the links on the first page are already up?

I don't know what requirements Kivy places on the graphics stack, but since Panfrost achieves OpenGL ES 3.1 conformance on Mali-G52, it certainly makes sense to read this to understand what to expect from a lima-driven GPU. I still remember very well times when my GPU only reached almost 2.0 and the performance was quite moderate. With now 3.1 it's a big difference for daily desktop use, although my GPU isn't yet declared fully compliant. But since this is bleeding edge development, at least the current mesa mainline release is required in any case. If not even the main branch to use just implemented extentions. Kernel driver wise everything necessary should already be available and therefor mesa is where you are looking for GPU support improvements.

A few days ago I also tried to build a ffmpeg with v4l2-request-hwaccel. Because my distribution already uses 4.4, I used these patches. Initially, I got similar error messages as @kprasadvnsi, but the 5.14 kernel header hint was the missing link. I also have a flawlessly compiled ffmpeg package now, but I also don't know if additional patches are needed for other mainline components or how to check the v4l2-request-hwaccel functionality.

Moved from the RK3399 multimedia integration thread to here, since the post is not related to the MM integration, and not even to Armbian.

Pull request mention HDMI specifically:https://github.com/armbian/build/pull/2302 
 
Although I not sure about what DWC3 driver limitation he is talking about. (HDMI+hub combo working fine for me on ROCKPro64 with legacy kernel.)