jock

armbian-config is not available in minimal installations, but you can install it via apt if you need it's configuration capabilities. It allows you to install software, desktop interface, configure timezones and locales, install Armbian to internal flash and lot's of other things. See the armbian documentation if you want further details.
 
You can do whatever you want with your box, you have a fully working debian linux box now.

Instead of using Volumio or Daphile, I installed Armbian_21.05.1_Rk322x-box_buster_legacy_4.4.194 to a MXQ Pro box. The box was shipped with Android 7, and I installed Devinfo to check if it is eMMC or NAND. It is lucky that my box equipped with eMMC, so I installed the OS easily. After that, I did some following steps:
1-     Run rk322x-config: I select CPU 3228B-1.4 Ghz, board 322x MXQ, wifi ssv6X5X
2-     Run nmtui to setup wifi connection
3-     Armbian-config: to add something such as infra red
4-     Set default sound card:
hai@rk322x-box:/etc$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: DWI2SHDMI [DW-I2S-HDMI], device 0: 100c0000.i2s0-i2s-hifi i2s-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: SPDIF [SPDIF], device 0: 100d0000.spdif-dit-hifi dit-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: DAC [USB Audio DAC], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: ANALOG [ANALOG], device 0: 100b0000.i2s1-rk3228-hifi rk3228-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
It means that my USB Audio DAC is card 2.
I revised /etc/asound.conf to make it contain only 2 lines
defaults.ctl.card 2
defaults.pcm.card 2
You can verify with alsamixer : it should display USB DAC as default.
5-     Install mpd and edit /etc/mpd.conf
…
# I will use usbstick to store the songs
music_directory         "/mnt/usb"
…
#you can set static IP for music server or add “any” as the address
bind_to_address         "any"
The other lines can be left as default
6-     Automount USB
Edit /etc/fstab to add the following line
 UUID=689E-CF4D /mnt/usb vfat defaults 0 0
Youn can find your usbstick UUID with sudo blkid
7-     The most difficult section is configuring infra red. Now lirc and /dev/lirc0 have been obsolate. We will have to deal with gpio_ir_recv (you can check with lsmod)
There are 2 steps here:
a-     Map the key name with keycode of your remote controller.
b-     Config a daemon to do the action you want while received the keycode.
At first, you should know which device is belong to your ir receiver.
hai@rk322x-box:/dev/input$ ll /dev/input/by-path/
total 0
lrwxrwxrwx 1 root root 9 May 21 21:17 platform-200a0000.hdmi-event-mouse -> ../event0
lrwxrwxrwx 1 root root 9 May 21 21:17 platform-30120000.usb-usb-0:1:1.2-event -> ../event2
lrwxrwxrwx 1 root root 9 May 21 21:17 platform-gpio-keys-event -> ../event1
lrwxrwxrwx 1 root root 9 May 21 21:17 platform-ir-receiver-event-mouse -> ../event3
In this case, /dev/input/event3 is my ir
And then I can run this command to check ir code:
hai@rk322x-box:/dev/input$ ir-keytable --device /dev/input/event3 -t -v
Opening /dev/input/event3
Input Protocol version: 0x00010001
Testing events. Please, press CTRL-C to abort.
1845.720102: event type EV_MSC(0x04): scancode = 0x113
1845.720102: event type EV_SYN(0x00).
^C
It will wait for you to push a RC button and show the code (0x113). After that, you can create a file to map keyname with keycode. I edited /lib/udev/rc_keymaps/samsung.toml
[[protocols]]
name = "samsung"
protocol = "nec"
variant = "nec"
[protocols.scancodes]
0x140= "KEY_POWER"
There are many *.toml files in the same directory, you can refer them to find the correct keynames.
Next, to make it consitent, you can edit /etc/rc_maps.cfg (its header guided you very clearly)
Add this line: gpio_ir_recv * /lib/udev/rc_keymaps/samsung.toml
 
Regarding step b, you should install triggerhappy.  
To config it is very easy. Just create a file under /etc/triggerhappy/triggers.d (any filename)
My file contains only one line: KEY_POWER 1 /usr/sbin/init 0 (use key power to shutdown the box)
 
Finally, you can test
sudo  ir-keytable -c -w /lib/udev/rc_keymaps/samsung.toml --device /dev/input/event3
Old keytable cleared
Wrote 1 keycode(s) to driver
sudo thd --trigger /etc/triggerhappy/triggers.d/ /dev/input/event3
 
If it can work well, you just need to reboot the box!
 
Important note: If you use MXQ as an audiophile music box, you must connect it to a linear power supply. Never use its equipped power adapter or any other pulse power supply.
 

Hi @ArkhanLK , I don't know what you did but I just tried the Focal image I gave you some days ago + the media framework script and everything went fine.
Installation was completed in a few minutes without any error, now I'm playing h.264 movie with Kodi without any issue.
 
edit: tried also mpv under X.org (work fine) and quake via glrun (utterly wrong, but those are the known issues of the Mali driver)

@ArkhanLK
These are the steps I did:
Installed the Armbian focal minimal image I published in the previous post on a sdcard Booted the image, run rk322x-config to configure the system for my board, then rebooted Downloaded the media framework tgz from the linked post on first page, unpacked it and run the installer script with sudo (probably you already know, but the script produces a log file in /tmp directory) Wait for a few minutes until the script finished, then rebooted the box Started kodi with start-kodi command, it booted and everything was smooth. Tried both to stream an mp4 movie from my NAS and also copied another movie on the local system; both movies worked very well with no issues at all. Just tried a few minutes, but everything was just right. Quit kodi, then run apt install --install-recommends armbian-focal-desktop armbian-focal-desktop-xfce lightdm lightdm-autologin-greeter armbian-config Run armbian-config and enabled desktop with autologin from System menu Installed mpv via apt, then run it with the command line of the post on the same movie of above: no problems Installed game data packager with apt install game-data-packare lhasa innoextract, then run it with game-data-packager -i quake to install quake Run quake from command line with glrun quake, it booted, acceleration was active, but there just were a lot of artifacts, but this is expected because of the old Mali drivers. As you see I did nothing particularly strange, maybe the step to install the desktop environment is better handler by armbian-config, but if you need the DE it is even better to use the stable Focal Desktop image.

@ArkhanLK I will try to take a look today if I have time

good news, today I succesfuly compiled the openvfd driver.
This is my DT Overlay:
/dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { openvfd { compatible = "open,vfd"; dev_name = "openvfd"; openvfd_gpio_clk = <&gpio2 0x13 0x00>; openvfd_gpio_dat = <&gpio2 0x16 0x00>; openvfd_gpio_stb = <&gpio2 0x12 0x00>; openvfd_chars = [04 00 01 02 03]; openvfd_dot_bits = [00 01 02 03 04 05 06]; openvfd_display_type = <0x03>; status = "okay"; }; }; }; }; Driver is working without any changes.
 

Your question was already answered the first time you posted your question.
There is an entire thread dedicated to discussing how to install armbiian on an rk322x tv box: https://forum.armbian.com/topic/17979-help-can-i-install-armbian-on-tv-box-with-r329q-v30-board/?tab=comments#comment-123847
 
 
This is now the third the you are asking the same question. It you ask a fourth time, I will consider you as spamming the forum and proceed accordingly.
 
 

Hello all nice people, let me do this post since I repute it very important.
There is a lot of people actively deploying things on rk 322x and rk 3318, some  media oriented things ( libreelec, kodi ) some desktop and servers applications.
Now.......it happens that @jock and my self are actively working on those two platforms because I was so lucky in the past to buy for really few bucks ( and i say FEW )  more than 50 different boards reputed faulty, and there were not, just wrong firmware.
But in this big STOCK of boards mostly were 322x ( 3228 3228a 3229 ) and ONLY ONE was 3318,and again I repeat just ONE 3318
 
So it happens that quite EVERY  question on 322x we can answer with sufficient level of accurancy, but on 3318 our experience is limited on HK1,  that is a circle box without display.
Every single help, every single uart log, bootlog any elselog is a mine of infos for us, in particular @jock , but at the same time is really hard provide you a satisfactory answer without debug info, our crystal ball is actually broken

Help us to help you providing as much infos possible and not just saying " it doesn't boot" because in that way is a hard stuff to solve.

Thanks

 

I've taken peeks at threads related to hardware decoding (of H.264 and HEVC, mainly) on Allwinner and Rockchip platforms on and off, sometimes dabbled in trying and failing to implement solutions recommended there. Being a complete amateur, I find the topic very opaque and confusing, with various different components that need to interface with each other, be patched in sync, and sometimes change drastically between kernel versions, etc. Today I sat down and read up on these subjects, scouring wikis, documentation, this forum, and assorted other sources to try and understand how this works. In this post I will attempt to compile what I've learned on the different software components involved, their relationships, their current status, and solutions to the problem. I hope people more knowledgeable will correct me when I get something wrong or cite outdated information. Stuff which I am highly uncertain of I will print in italics.
(This post is going to focus on mainline implementations of Cedrus/Allwinner, I haven't looked into Hantro/Rkvdec/Rockchip specifics yet. I will speak only of H.264 and H.265/HEVC; I don't understand the high/low stuff and didn't pay attention to other codecs.)
 
Components:
 
Basics: Video codecs like H.264, H.265/HEVC, MPEG-2, etc. are standardised methods which serve to more efficiently encode and decode videos, reducing their filesize. Software en-/decoding is very CPU-intensive. Modern GPUS and ARM SoCs therefore contain specialised hardware (VPUs) to delegate these tasks to. Working hardware decoding is particularly important for underpowered ARM CPUs.
Drivers: Topmost in the stack are the VPU drivers. These are Sunxi-Cedrus/Cedrus V4L2 M2M and Cedar [Is this the legacy one?] on Allwinner; Hantro and Rkvdec on Rockchip. These are all still in development, but Cedrus already fully supports H.264, and partially supports HEVC, and is already usable in the mainline kernel.
APIs: In order for anything (userspace APIs, libraries) to make use of the VPU drivers, you need backends/APIs. For Cedrus, there is the unmaintained libva-v4l2-request backend which implements VA-API, the legacy VDPAU implementation libvdpau-sunxi, and as of kernel version 5.11, H.264 has been merged into the uAPI headers. Different applications may make recourse to one or another of these APIs.
Libraries: FFmpeg and GStreamer. provide libraries and APIs of their own to other applications but can (importantly!) also output directly to the framebuffer. FFmpeg must be patched to access either libva-v4l2-request or the Cedrus driver headers. GStreamer directly accesses kernel headers since 1.18 (works on 5.9, not on 5.10; 1.20 will support 5.11.)
Media players: mpv and depends on FFmpeg for hardware acceleration (and must be patched together with it). VLC can be set to access libva-v4l2-request directly. Kodi 19.0+ supports hardware acceleration out of the box without any out-of-tree patches.
Display server: An additional complication is drawing the output of any of the above on screen. Most successful implementations I've seen bypass X11 and either output directly to the framebuffer or force a plane/display layer on top of any X windows. Wayland apparently makes this easier by allowing applications to use their own DRM planes, but this hasn't been explored much yet. Kodi 19.0 works with all three windowing systems (X, Wayland, and gbm).
 
Codec status:
 
Taken from the LibreElec thread (which reflects LibreElec's status and is ahead of what works elsewhere, but outlines hardware limitations):
 
 
Approaches:
 
Many people have managed to make it work on their machines using different approaches. Note that some of these solutions are one or two years old, and kernel developments since may have changed the situation. Ordered from newer to older:
 
LibreElec – kernel + ffmpeg + Kodi: LibreElec is a Just-Enough-OS with the sole purpose of running Kodi, a media player. It's at the bleeding edge and usually implements codecs and features well before mainline or other distros. It achieves this by heavily patching everything up and down the stack, from the Linux kernel over FFmpeg to Kodi itself. These patches could all be applied to an Armbian build, but there are a lot of them, they're poorly documented, and you'd need to dig into their github to understand what they all do. LibreElec runs Kodi directly without a desktop. kodi-gbm is a package that can be installed on Armbian and functions similarly.
Key contributors to the project are @jernej and @Kwiboo, who sometimes post about their work here (and have been very helpful with questions, thank you). @balbes150 includes some of LibreElec's patches in his Armbian-TV builds, but I don't know which.
 
Kodi 19.0: 
 
LibreElec patches + mpv:
 
 
@megous – Kernel 5.11 + GStreamer: This implementation, done here on a PinePhone (A64), patches the 5.9 kernel and uses a recent version of GStreamer (1.18 and up), whose output is rendered directly to a DRM plane via kmssink. (No X or Wayland.)
GStreamer 1.18 works with the 5.9 kernel. It does not work with 5.10, because of numerous changes to the kernel headers in this version. In 5.11 the H.264 headers were moved into the uAPI; the master branch of GStreamer reflects this, but there haven't been any releases with these patches yet. It'll probably be in repositories with GStreamer 1.20; until then you can build it from source.
 
@Sash0k – patched libva-v4l2-request + VLC: This updates bootlin's libva-v4l2-request and follows the Sunxi wiki's instructions for enabling VLC to make use of it. It works on the desktop. This only works for H.264 and breaks HEVC. When I tried to replicate this approach on a recent Armbian build, I discovered that the h264.c files in the kernel (that libva-v4l2-request draws on) have changed considerably between 5.8 and 5.10, and I lack the understanding to reconcile libva-v4l2-request with them.
 
@ubobrov – old kernel + libcedrus + libvdpau-sunxi + ffmpeg + mpv: This approach, which supports encoding decoding of H.264 uses the libvdpau-sunxi API and ports the legacy driver to mainline as a loadable kernel module and if I understand it correctly, ubobrov ported a legacy feature to mainline. In the post quoted below the kernel is 4.20, but the same method has been successfully applied to 5.7.8 by another user. It requires that the board's device tree be patched, as documented in ubobrov's github repository.
 
 
The summary seems to be that none of the current implementations on Allwinner boards really play nice with X or desktop sessions, and it's best to output directly to the framebuffer. Kwiboo has forked FFmpeg and mpv to make good use of new and unstable kernel features/hardware acceleration which will take a while to make their way upstream. The recent 5.11 move of stateless H.264 out of staging and into the uAPI should facilitate further developments.
I intend to try some of these things in the nearer future. Thanks to everyone who works on mainlining all of this VPU stuff, and to users here who contribute solutions and readily & patiently answer questions (Jernej especially). I hope I didn't post any falsehoods out of ignorance, and welcome any corrections.
 
Other related threads here:
https://forum.armbian.com/topic/11551-4kp30-video-on-orange-pi-lite-and-mainline-hardware-acceleration/
https://forum.armbian.com/topic/16804-orange-pi-pc-h3-armbian-focal-5104-sunxi-av-tv-out-cvbs-enable/page/2/
https://forum.armbian.com/topic/11184-hardware-graphicvideo-acceleration-in-h3-mainline/
https://forum.armbian.com/topic/13622-mainline-vpu/

hmm, ok. Good point is that MultiTool is booting... Are you able to retrieve the DTB from Android backup?
Someone from this forum can look into, to find the problem.

Also best would be to have the serial console...
 
EDIT: also you can look at LibreELEC, if there is something for your box and if yes, then you can try to combine the u-boot/dtb from LibreELEC with armbian distro.
Something is here:
https://forum.libreelec.tv/thread/20813-step-by-step-tutorial-libreelec-on-h96-max-also-ir-remote-support/
But I am not sure if this box is compatible with your.

When you will be experimenting, don't flash to the internal memory. Always use the SD card.
Otherwise there is a big risk that your device will be bricked.

@Dragao, for better understanding - you have a two options:
 
1) Boot from external media (SD Card or USB key) - in this case you need only to write the distro image to the media and put it into box and boot. After booting you can run rk3318-config to configure additional devices (wifi, led, ...) In this case MultiTool is not required.
 
2) Boot from internal eMMC - in this case you can use MultiTool to flash the distro image to the internal eMMC, and boot.. Again you can use rk3318-config for further tuning.
 
Both options are described in the first post.
 
I think, you don't need to manipulate dtb/dtbo manually, also I think MultiTool do nothing with dtb/dtbo..
 

Hello, I neither have the boards you have nor the AP6212 wifi chip in any of my boards, but I can tell you that bluetooth is generally quite a beast.
I have had experience with AP6330 and AP6334 (a clone, actually) and spent countless hours trying to sort things out.
 
First of all, the bluetooth adapter on the same chip of the wifi, but is actually a separate device. The wifi part is connected to the system via SDIO bus, but the bluetooth is connected via a simpler UART serial port.
The dmesg logs you provided are not showing anything related to the bluetooth hardware part, but just some software modules/components, you should provide the complete dmesg log (please put them in a spoiler section), because things happen in out-of-order fashion when device are initialized.
 
Anyway, if you are very very lucky, running hciattach is everything you need:
/usr/bin/hciattach /dev/ttyS0 bcm43xx 1500000 the program will not put itself in background, and you need to keep it running if you want to access bluetooth device. In case it works, you may want to create a systemd service or a script that runs at boot.
Change ttyS0 with the serial port your bluetooth adapter is internally connected.
You may need to put the right firmware file in /lib/firmware/brcm, I don't know which one is required so you have to discover it by yourself. Maybe it is already there.
 
In case this does not work, debugging may take ten minutes to several hours/days and unfortunately requires quite a knownledge to deal with.

@ArkhanLK you're too kind
Well the media framework was compiled with a Focal of one year ago or so... maybe the packages have been updated in the meantime and now they are not compatible anymore - that's the only thing I can think about.
Actually nothing is really tied to lightdm, armsoc is a general driver for X.org and maybe something changed in X.org with latest Focal packages that made it not work anymore.
It is very curious rkmpp does not install though, as far as I remember it had no very important dependencies.
Did you install the packages via apt-get install or via dpkg? The script uses apt-get install to solve automatically the dependencies and that would be the only sensible way.
 
To be honest, the box is quite capable to run x264 and x265 1080p streams in Kodi with ffmpeg + rkmpp.
I should try lubuntu, Armbian is historically tied to xfce but I'm not very fond of. Also it is always suggested to disable window compositing for xfce because the desktop will feel very sluggish with it on, but the media framework should disable it by itself.

Here it is!
It's still weird you have building issues with Focal too, in a step (write uboot) that is mostly just bash scripting...

Hmmm... yes, it is indeed contradictory... The "native" building should be referred to building armbian on the board itself, but there is an "x64" there which adds more contradiction confusion.
By the way, I'm using Focal to build Focal, Buster and Bullseye images and it works fine. Historically the supported distribution for x86-64 building was the latest Ubuntu LTS. There is only a bug in the build system that I don't know if it has been fixed yet, but you may need to install some packages manually (like libfdt), but then it should go on without any more issues

Hello @ArkhanLK, be aware of this:
 
so everything else is a moving target. The tools may work differently on other distributions, with subtle bugs or even build failures, so it is preferable to support a single distro and support it well.
Personally, I have my 100Gb Ubuntu Focal 20.04 Server virtual machine to do such jobs.

Hi @gnusmag45, I'm sorry you are having issues with your board. I hope the multitool still boots after you erased the flash
Unfortunately your board has an eMCP, which is a chip that contains both the eMMC and the DDR memory. I never had the chance to test a board with such chip by myself, so it is totally guesswork.
 
The multitool has a dtb which is usually very compatible because it does not use any "advanced" features of the board, and also uses lower operating frequencies to maximize compatibility at the expense of performance. Something does not work for your board although.
 
I edited the device tree of the multitool to provide more current strength to the eMMC pins and also some other configuration that may be of some benefical effect for your board.
 
This is the dtb: rk322x-box-emcp.dtb.
Put it in the root directory of the multitool, then edit the the file extlinux/extlinux.conf and change the existing rk322x-box.dtb with this rk322x-box-emcp.dtb.
Save the conf file and try again to boot the multitool. Check if after some reboots the flash memory is detected consistently, maybe make a backup to "stress" it and see if the backup is completed correctly, but don't install any armbian image yet.
 
I suggest you to first try to burn an Armbian image directly on the sdcard and boot armbian from sdcard. This may let you upload a full set of logs (via armbianmonitor -u) to the internet and let us inspect them before proceeding to install the image on the eMMC.
Also check if the eMMC is correctly detected within Armbian after some reboots: it is important that the kernel detects it otherwise even if you install Armbian on eMMC it won't boot anyway.

Yeah, you're right, the emmc-nand overlay also enables the DDR mode... I forgot I added that thing there too.
Need to fix that in rk322x-config to be more clear about.

Thanks a lot, this makes the job worth it You're right, that's not just me behind this, so I share the greetings with all the people that helped in this thread!
 
You can still use Focal Legacy and configure icewm desktop manager even if the image comes preinstalled with xfce, performance should be the same as debian.
Unfortunately I didn't try on debian. Roughly it should be possible to make it run on, but the package names to resolve the library dependencies changes, so the media packages should be adapted. It was a bit hard to find and fix dependencies, I'm no .deb specialist at all.
Also Debian Buster comes with some very old packages that should be recompiled and installed manually... it's a bit of headache
You can extract the script and install each .deb packages manually using apt-get (apt-get install ./the-package.deb), but I don't really know if it brings you anywhere.
The new developments on the mainline kernel brings new life to hardware decoding and acceleration, but things are still settling down, as you may notice with the release of the first beta versions of LibreELEC 19 and Kodi Matrix: actually I managed to get hardware acceleration work fine on mainline kernel, but the process still requires patching and manual compilation of ffmpeg and Kodi, so there still is some time to wait for.
Ah, no there is not any tutorial I know about for that, but IMHO it does not really worth it.
CPU and GPU can be overclocked easily editing the device tree, finding the opp tables (OPerating Points), and modifying frequency and voltages. I don't recommend it, the improvement is very modest at the expense of much greater heat production.
Unfortunately the CPU is a Cortex-A7, a very old 32 bit only architecture made to do cheap tv boxes. The SoC has dedicated hardware decoding blocks, which are nice, but the hardware specs are minimal for the current standards. It is perfect for some home server things although (network router, NAS, VPN endpoint, dns cache/hole, etc...)
 
edit: about the boot issue, follow the @RaptorSDSadvice to remove the emmc word from overlays= line in /boot/armbianEnv.txt, or just select emmc-nand in rk322x-config.

Amlogic has quite good performance/price ratio: their low-end S905X3/X4 are very good chips for the price, and quite updated too (Cortex A55). Rockchip and Allwinner have nothing comparable yet for the price. Allwinner is far behind. Rockchip recently introduced the long-awaited RK356x series which at least is on par with raw performance to S905X3 and has a nice set of features, but the price is clearly higher and support is still going on. RK3328 is not as good as S905X3, either from CPU and GPU sides, but the RK3399 is still quite good SoC. Amlogic has the best chip on paper with S922 (and similar ones), but in the past they did some double-cross with frequencies and temperatures so people is reasonably skeptic on the real performances.
Despite lagging behind, Allwinner chips are at least very cheap with decent raw performance (H6 at least), but the company is a bit silly.
 
About linux and community support, Amlogic is the worst one by far, being quite obscure about their hardware and generally not very supportive of opensource.
Rockchip is the best one, a lot of their drivers are production ready in the mainline kernel. Recently although I saw quite a stop in their "proprietary" kernel and u-boot public forks. I don't know why they stopped, but I hope it's just a temporary reorganization: the effort they did in supporting opensource was very appreciated by the community and mainline kernel is very advanced on supporting their chips and peripherals.
Allwinner in the past was a total wreck, a lot of work by community has been done to reverse engineering things with excellent results and I think they now opened a bit more publishing especially documentation.
 
My two cents.

https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09

Nah, all good from here. I'll try to do the release this sunday. Might hop in the IRC if I need assistance. Release on sunday evening is good IMHO because if something critical goes wrong, we can fix on monday.

Sometimes disreputable manufacturers will modify the kernel in the android firmware to provide false information. (easy way to cut costs by not actually including the memory/storage advertized).

Armbian project does not officially support nor maintains tv boxes. Armbian project maintains only supported Single Board Computer (SBC) devices. SBCs have stable hardware (kind-of), and are usually well-documented.
 
Tv boxes are another thing.
In the ideal world of the naked puffy angels chanting melodious high-tone songs, the organization you proposed would be perfect.
In our world full of crap, dirt and oil it does not work at all: every chinese tv box manufacturer buy chips at the lowest price point possible on the market and put all that crap and scrap on these boards. If you read carefully the first post (and I invite you to do it) the very same rk3318 is probably a scrap chip, and eMMC chips are often failing after a while, some because are faulty, some others fail because of crappy soldering (you can ask @fabiobassa how many faulty eMMC chips desoldered from these boards).
 
That's why Armbian does not officially tv boxes: it's a community matter, because keeping the things working with a huge hardware variety is just too difficult and very time consuming.
In a world were everything can fit onto these boards, having one image for each box is unthinkable; I preferred a more elegant solution that allows the user to download a single image with a basic configuration that (hopefully) boots on every board with the same SoC. Once installed, the system can be further configured by the user herself to enable all the features of the board, like higher cpu speed, wifi, bluetooth, eMMC higher speed modes, leds, buttons, etc... etc...
 
You won't find images of mine spread here and there on the forum, usually I publish images just on the first page of this thread and sometimes I prepare some special testing images for someone who has willingness to help the development progress. When everything will be stable enough, I will ask for merging to the main Armbian project, so the images will not be built and published anymore by me, but the Armbian server will build (and certify) them and they will be available in the official download page, but still totally backed and maintained by community efforts.
 
You will find everything you need to get the thing running on the first page of the thread, so read that carefully and, if you're not satisfied, steer away from tv boxes and search for a proper SBC.

Armbian project does not officially support nor maintains tv boxes. Armbian project maintains only supported Single Board Computer (SBC) devices. SBCs have stable hardware (kind-of), and are usually well-documented.
 
Tv boxes are another thing.
In the ideal world of the naked puffy angels chanting melodious high-tone songs, the organization you proposed would be perfect.
In our world full of crap, dirt and oil it does not work at all: every chinese tv box manufacturer buy chips at the lowest price point possible on the market and put all that crap and scrap on these boards. If you read carefully the first post (and I invite you to do it) the very same rk3318 is probably a scrap chip, and eMMC chips are often failing after a while, some because are faulty, some others fail because of crappy soldering (you can ask @fabiobassa how many faulty eMMC chips desoldered from these boards).
 
That's why Armbian does not officially tv boxes: it's a community matter, because keeping the things working with a huge hardware variety is just too difficult and very time consuming.
In a world were everything can fit onto these boards, having one image for each box is unthinkable; I preferred a more elegant solution that allows the user to download a single image with a basic configuration that (hopefully) boots on every board with the same SoC. Once installed, the system can be further configured by the user herself to enable all the features of the board, like higher cpu speed, wifi, bluetooth, eMMC higher speed modes, leds, buttons, etc... etc...
 
You won't find images of mine spread here and there on the forum, usually I publish images just on the first page of this thread and sometimes I prepare some special testing images for someone who has willingness to help the development progress. When everything will be stable enough, I will ask for merging to the main Armbian project, so the images will not be built and published anymore by me, but the Armbian server will build (and certify) them and they will be available in the official download page, but still totally backed and maintained by community efforts.
 
You will find everything you need to get the thing running on the first page of the thread, so read that carefully and, if you're not satisfied, steer away from tv boxes and search for a proper SBC.