SteeMan

What exactly have you installed on the SD card (version, image name), and what steps have you used to install?

What you are reporting is quite common with tv boxes. The case markings often are different than the internals. What is it you are looking for? Your post didn't really ask for anything other than to report that you got a common tv box with internals that differ from the case.

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)

First off, why do you want to? As the name 'edge' should imply, edge kernels are development kernels that are for testing purposes and may or may not work, and may break at any time. 'current' 6.12 in your case are LTS kernels that should be stable and more suited for non-development/testing use cases. If you do want edge kernels then you can use armbian-config to switch.

Lack of feature implementation, not a bug. 6.1 is the vendor supplied kernel where most things will work, but the vendor doesn't provide support. 6.12 is linux mainline kernel, where much functionality may be missing (as the vendor doesn't work to get their features into mainline linux, but relies on others (volunteer opensource developers) to do their work for them).

Per the install instructions on this site, if you have ever booted a different distribution then your box will be incompatible with the Armbian build. Although it is generally using coreelec builds that will do this. I don't know about the libreelec builds. Also you need to provide a lot more information about what you are doing. There are a number of steps in installing armbian on a TV box and you haven't specified any of the steps you performed. Finally debugging boot issues often requires that you find the debug serial console connection on the board and hook up a usb uart reader to get at the boot messages.

What download are you using? There is no meson-gxm-s912-mecool-bb2-pro.dtb in Armbian builds.

No one has ever submitted this for inclusion in Armbian. This is a community supported board. If anyone were to submit this as a PR it would almost certainly be included as the approval process for community supported boards is a low bar, basically that it doesn't break the build.

Read the instructions from this site. It will tell you that if you have ever booted another os like coreelec, you will have made your box incompatible with the Armbian build.

@pochopsp You would need to use the information in that readme and patch and apply it to a newer u-boot (i.e port the patch to a newer u-boot) and build then a newer u-boot than the 2020.07 currently shipped.

Yeah that won't work as that code has no support for extlinux. The extlinux way would be to add a line FDTOVERLAYS /path/overlayfilename.dtbo to your extlinux.conf file. Again, I haven't tested this, (I've had no overlays that I've needed to use for anything), but theoretically this is supposed to work.

I'm curious what you mean by this. I thought they were working via the extlinux.conf way of specifying them (although I will admit I've never tested this).

Also, did you experiment with this alternative to openvfd?

Did you try doing this with a device tree overlay file instead of editing the device tree? That way on kernel upgrades you shouldn't need to redo the device tree edits each time.

The issue is that your u-boot can't read the emmc. The linux kernel can since when it was run from your sd card you can access the emmc. But after you have copied the install to emmc and then boot, the uboot is reporting it can't read the emmc. There are instruction in /boot/build-u-boot for building the various uboots. I would suggest you try building with a newer version of uboot. What is currently shipped (the u-boot-s905x-s912 was built from uboot 2020-07 sources) so trying with newer uboot 2025-xx might provide better support for your specific emmc.

What CPU does your box have? This should be filed under the corresponding CPU archtecture sub forum.

Also note that if you are on a community build or anything that points to the "beta" armbian apt repository, you will get a new linux kernel image pushed out to you each day, which would then trigger the need for a reboot (depending on settings) for that new kernel to be run.

@Qvy Are you sure you actually have emmc and not the older plain nand? Android kernels have support for raw nand. That support never was put into mainline linux as emmc became the standard. A lot of older TV boxes used raw nand as that was cheaper at the time. And sometimes identical looking boxes will have different components. For example I have TX3 Mini boxes that some come with emmc and some come with nand. And only those with emmc are supported by mainline linux kernels.

What type of monitor do you have connected? If you have another monitor, I'd try that. What I find works best is a monitor that is native 1920x1080. I sometimes have issues with monitors that are higher resolution or lower resolution than a standard 1080P display. Otherwise finding the uart pads is the only other advice I have, so that you can see what is going on during the boot.

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.

Currently yes. A replacement for this package / service needs to be found and implement - in case you want to get involved. 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.

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

There are those of us that spend months working on these things. There is nothing about this that is easy. It is a hobby to waste a lot of time on. If you really wanted to proceed further you are really going to need to hook up to the debug serial port to get an ideal of the boot messages that are occuring. From an earlier post it looks like the serial connection points were identified and hooking up a USB serial adapter to them would give more information. But getting a random TV box working is usually a many month project as a lot needs to be learned about this while environment first.

No, the support for rk3399 is quite good. The problem is that each box/board needs someone to develop a device tree (dtb) for that box/board and each is different depending on the specifics of that box/board. That is what is lacking to support your box. (and if your box has obscure hardware on it, then those drivers may also be lacking)

You are missing something. The boot process starts with the uboot from the emmc (even if ultimately booting the SD card). And coreelec changes the uboot environment of the emmc in ways that are incompatible with with the armbian code. So you need to reflash a fresh android image if you want to use armbian as that will restore the basic state that armbian is expecting.