jock

@primoitt: @ilmich solved it for me by compiling a libreleec 11 build with mpv binary included- Everything works, h264/hevc/mpeg2 ..... brilliant.

@Vittorio Mori Hardware video decoding is available since kernel 5.10 on armbian, thanks to libreelec patches, but the userland part is a bit worrysome.
You can try with this, but it is a very old post and very old binaries that probably don't work on recent kernel because it is more than one year old.
 
The problem is that ffmpeg never really stabilized the v4l2-request kernel api, thus you have to compile the libreelec patches version and then supply the static libraries to mpv to gain hardware video decoding via v4l2-request.
 
I don't know if recent ffmpeg 6.0 release include working support for v4l2-request or there is the need to still use the libreelec patched version.

Hmmm that's odd, I applied the same "fix" @ilmich applied on libreelec but it didn't work. The serial log output could have been very handy here; we will think about what could be wrong and maybe some other idea may pop up.

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.

@SuperMaximus  What exactly are you trying to accomplish and why?  In your post in this other thread (https://forum.armbian.com/topic/21590-rotate-armbian-logo-in-startup-splash-screen/#comment-161028) you are asking about changing the boot logo, here you are asking to disable the video output.  Those are very different things.  I think if you are looking to disable video output during boot, @jock suggestions are the way to go, and yes that is invasive and would involve low level changes that would require building a custom image.  If you are looking to change the boot logo as you indicated elsewhere, then look at my followup post to that.  If you are looking to do something else, you need to be more specific in your question.  Otherwise Jock and I are wasting our time trying to guess what you are trying to accomplish.
 

@ochentay4 I set up a multitool image with the same fix proposed by @ilmich on his libreelec image. This fresh build is totally untested, but you can download a copy from here and test by yourself. Perhaps this solves @n3o problem too.

Hello folks, sorry for the absence, I've been facing connection issues.
Let me try and explain a bit, from the beginning. I will focus on kernel, but most applies also to u-boot, firmware, etc; also keep in mind that not all packages have been migrated to the new scheme: BSPs, Desktop BSPs, etc, are not yet changed (too many things to hash / little benefit / too many things to decide before that).
 
The reason we've a new version scheme is for consistent caching and fast CI runs.
The important part about the caching is that we need to obtain the "desired" version of the kernel, **before** actually git clone/fetching the sources, before patching, and before compiling; otherwise it's useless: if the user/developer has to do any/all of this to get to the version, then it's "too late" for caching. This needs to be crystal clear, otherwise everything just looks like an insane person did random stuff and broke Versioning for no reason.
 
Important: the caching part benefits some users/builders, in the sense that someone casually building an image at home might hit the cache, but the main target/reason it exists is for our (Armbian) own Continuous Integration (CI): every PR, every nightly, every release, etc, should benefit from the caching, but it has to be consistent (not use wrong version), and hit ratios should be high. Before this scheme, we had only REPOSITORY_INSTALL mechanism, which frequently installed wrong/mismatched versions, we just said "use whatever is in the apt repo", which could be literally anything, and frequently led to half-working images.
 
Also, "apt repo" is a very inflexible/demanding solution in terms of infrastructure, which requires HTTPS servers/mirrors, Release lists, etc, and is not available for free for every developer/partner. New caching uses standard OCI registries, which are available for anyone to host, and even hosted for free on GitHub (ghcr.io) and DockerHub among others.
 
That said, let's get to how we calculate the version for the kernel package. The code, containing a long explanation, is at https://github.com/armbian/build/blob/main/lib/functions/artifacts/artifact-kernel.sh - but in essence goes like this:
 
1) "base_version" (bv): Get the KERNELSOURCE and KERNELBRANCH variables (usually set in family config file for the board being built). Use `git ls-remote` to obtain the SHA1 of the commit of that. Obtain the HTTP URL for the Makefile at that commit. ("View raw" in GitHub web interface, but also for GitLab, and others). Get the Makefile contents (using HTTP, not Git, since there is not "partial git fetch"). Parse the Makefile for the version information inside, including the "codename". (Codename here is just to "prove" that data comes from Makefile, not "git tag"). Cache all this on disk for a few minutes.
2) "S"ha1: just the SHA1 of the commit mentioned above. 
3) "D"rivers: Obtain a SHA256 hash of the "drivers". Kernel drivers (EXTRAWIFI etc) are just a complex variation of patches; they are shared across families, and are not stored as patches, but in the end are transformed into one huge patch, so behave like one.
4) "P"atches: Obtain a SHA256 hash of the "patches": simple hashing of the patches/series/etc under KERNELPATCHDIR (and userpatches variations). If no patches, "0000" is used.
5a) "C"onfig: Obtain a SHA256 hash of the ".config" file that is gonna be used for the build. LINUXCONFIG (and userpatches variations).
5b) "H"ooks: Obtain a SHA256 hash of the hooks that might modify the .config. (This is a bit more complex to explain, since it involves extension mechanism, which is out of scope here). Suffice to say that if you change a hook that changes kernel configuration, the version should change.
6) "B"ash: Some lib/framework code, if changed, should cause the version to change as well. Not all bash code, but bash that calls the "make", or does the packaging, if changed, need to change the version. Currently "lib/compilation/kernel*.sh" is hashed.
 
Hopefully, you can now understand that `Version: ` below. Each SHA256 hash is shortened to a mere 4 characters:
 
 
 
So now we've to address two things: a) the original question by @belegdol; b) the general question of "how to control upgrades via apt".
 
------------------------------------------------------------------------
 
Ref the "odroidxu4" situation: @belegdol maintains that kernel family, in the following way (please correct me if I'm wrong):
a) Vendor, HK, has an  Git repo, which has a 5.4.y version, plus HK/Exynos patches. That Makefile currently says "5.4.228". It has heavily lagged behind official releases in the past AFAIK but seems pretty recent recently. HK "merges" updates from mainline, instead of cleanly rebasing, though, since they've lost all hope of mainlining their stuff and merging is easier.
b) Belegdol extracts new/recent 5.4.y patches from upstream/kernel.org, (possibly?) manually fixes them so they apply cleanly on top of HK kernel, adds them to Armbian via PRs. Those patches modify the Makefile so the version is incremented.
 
So AFAIK this is the only kernel family that is done this way (we did some similar stuff for rk3588 legacy, but thankfully no more). Every other family works in reverse: we start with a pristine/clean/updated kernel.org branch (whose Makefile is updated), and then patch what is needed on top of that. That way the kernels "auto update", unless some patch breaks.
 
Hopefully it is clear, together with the above explanation, why the  "wrong" version is used: only the original Git's Makefile version (not tag... but tag's Makefile's contents) is considered, since patches are only ever applied after Version is calculated, and cache possibly hit or missed.
 
So while I confess I had not xu4 as the primary target of this whole thing, it representing less than 1% of all boards. Still, there needs to be a way to make it work, we just need to decide how.
 
One possibility: invert the XU4 patching scheme, by rebasing HK's branch onto an upstream tag, and extracting the patches (git format-patch); then change our KERNELSOURCE/KERNELBRANCH to mainline, and let it auto update. This might, or not, be a lot of work initially, and might, or not, impose a lot less work over time. It depends on how many changes there are in HK Git, if the relevant patches are constantly updated, etc. From what I hear HK has little work done on the Exynos, but I am not an expert. I would like this scheme since it would align XU4 with the rest.
 
Another possibility: introduce a way to (optionally) override the "base_version" (example, variable FORCE_KERNEL_EXACT_VERSION_VIA_PATCHES="5.4.232") directly in the family configuration, use that for the artifact version if present, and change nothing else. This is _more_ work for xu4 maintainer, and might be get out-of-sync with reality (change patches, but not change variable, and vice versa). This might be useful also for other situations, although none come to mind right now, it might be useful for Igor's "emergencies" 😉
 
------------------------------------------------------------------------
 
Now about "how to control upgrades via apt". 
 
To understand this, we need to understand the formally defined Debian Policy about the "Version: " field in the DEBIAN/control file.
I recommend we all read https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version -- it is one of the more dense, complex, and important paragraphs of text ever written by Debian, and defines how apt decides what version is "higher" than another.
There, we can see there are 3 components, each with its own rules, and the special rule about the "~" (tilde) character.
 
The important part: I did not want to "impose" the final apt versioning scheme before we talked about it.
Also: there's pending work in the general area of "repository management/publishing" that needs to be done before we can publish _anything_, consistent or not, to any apt repository. 
I was told we had until May/2023 (so circa 2 months) to reach consensus and implement those -- but now it seems the sky is falling down much earlier?
 
So current "Version: " is a non-working, non-deterministic, inconsistent situation in regards to apt upgrades: if you try to predict how our "bv+S+D+P+CH+B" will be handled by apt, you will soon realize it's inconsistent: "fixed"/later patches on same base version might get downgraded to broken ones, and vice versa, almost randomly (as is the property of SHA256 hashes).
 
One extremely easy way to "fix it" is to prefix our current "bv+S+D+P+CH+B" with the $REVISION (which comes from VERSION file or equivalent userpatches) and a tilde.
That would force apt to respect the "old" versioning scheme, while still keeping caching consistent.
Unfortunately, doing that would drastically decrease cache hit ratio, since changing VERSION file would cause an otherwise identical kernel to be ignored/rebuilt. That might happen because user/dev changed userpatches/VERSION, but is otherwise identical to main, or because we branched off a release/tag (otherwise identical to main at that instant).
 
But it might be the best option right now, especially if no-one else is willing to invest brain time on this. I could then twist my own brain on how to recover the cache hit ratio somehow else (eg, search cache for both with-$REVISION and without-$REVISION variants, invent some "IS_RELEASE=1" variable, doing GitHub Actions acrobatics, etc; is a lonely world where only Igor and Ricardo live).
 
Similar option: transforming $REVISION ("23.05.01") into an integer (230501) and using that as the "epoch" part of Version field, would also work, but same cache-non-hitness applies.
 
-----
 
Phew, that was long. If you read all this, give yourself a pat in the back. Let me know what you think on all the different points... @going @Werner @belegdol @Igor @SteeManand everyone else interested.
 

inside linux
goto /boot
open with nano or other editor  armbianEnv.txt
add the new line cpu-stability
save and reboot

DISCLAIMERS (PLEASE READ):
Everything you can find in this thread (binaries, texts, code snippets, etc...) are provided AS-IS and are not part of official Armbian project. For this reason not people from Armbian project nor myself are responsible for misuse or loss of functionality of hardware. THIS POST explains very well the troubles with TV Boxes and why they are not suitable for everyone Please don't ask about support or assistance in other non-community forums nor in the official Armbian github repository, instead post your questions in this thread, in the TV Boxes forum section (hardware related) or in the Peer-to-peer support section (general linux/software related).  
Following the recent thread on LibreElec forum about an unofficial image for rk3229 devices, I would like to make public the work made by me and @fabiobassa about bringing rk322x support to armbian.
The project is now in -> mainline Armbian <- development fork -> here <-
 
This first page and the last 3 or 4 pages of the thread are enough to get up to date with recent developments.
Many useful experiences are scattered through the thread, but the most important things are collected here in the first page, so please read it carefully!
 
Mainline kernel is fully supported and will receive most support in the future. Legacy kernel 4.4 is deprecated, but is kept around only for special purposes.
 
What works:
Should boot and work flawlessy on all boards with RK3228a, RK3228b and RK3229, with either DDR2 and DDR3 memories. Mainline u-boot Proprietary OPTEE provided as Trusted Execution Environment (needed for DRAM frequency scaling) All 4 cores are working Ethernet Serial UART (configured at 115200 bps, not 1.5Mbps!) Thermals, CPU and DRAM frequency scaling OTG USB 2.0 port (also as boot device!) EHCI/OHCI USB 2.0 ports MMC subsystem (including eMMC, SD and sdio devices) Hardware video acceleration NAND is available only on legacy kernel. To fully boot from NAND, use the Multitool and its steP-nand installation (instructions are below) Various WIFI over SDIO are supported (SSV6051P, SSV6256P, ESP8089, Realtek chips, etc...), ssv6256p driver is available only on legacy kernel Full GPU acceleration U-boot boot order priority: first the sdcard, then the USB OTG port and eventually the internal eMMC; you can install u-boot (and the whole system) in the internal eMMC and u-boot will always check for images on external sdcard/USB first.  
Unbrick:
Technically, rockchip devices cannot be bricked. If the internal flash does not contain a bootable system, they will always boot from the sdcard. If, for a reason, the bootable system on the internal flash is corrupted or is unable to boot correctly, you can always force the maskrom mode shorting the eMMC clock pin on the PCB. Here there is the procedure, but you can also google around if you get stuck on a faulty bootloader, the technique is pretty simple and requires a simple screwdriver.
 
There are however some unfortunate cases (expecially newer boards) where shorting the eMMC clock pin is difficult or impossibile, like eMMC or eMCP BGA chips with no exposed pins. In those cases pay double attention when burning something on the internal eMMC/eMCP and always test first the image from the sdcard to be sure it works before burning anything on eMMC/eMCP.
 
Some useful links with pins, pads or procedures for some boards:
Generic procedure for boards with non-BGA eMMC MXQPRO_V71 - eMCP H20 - eMCP ZQ01 - eMCP  
NAND vs eMMC vs eMCP difference:
RK3228 and RK3229 tv boxes comes with three different flash memory chips: eMMC, NAND and eMCP.
It does not depend upon the market name of the tv box and neither the internal board; manufacturers put whatever they find cheaper when they buy the components.
 
NAND chip is just the non-volatile memory eMMC chip contains both the non-volatile memory plus a controller. eMCP chip contains the non-volatile memory, a controller for the non-volatile memory (like eMMC), but also contains a bank of DDR SDRAM memory on the same physical chip.  
The difference is very important, because eMMC and eMCP are far easier to support at various levels: the controller deals with the physical characteristics of the non-volatile memory, so the software has no to deal with.
NAND chips instead are harder to support, because the software is required to deal with the physical characteristics and non-standard things that depends upon the NAND manufacturer.
 
If you have a NAND chips you're unlucky because mainline kernel currently cannot access it, but also because you need special care and instructions explained later.
 
You can discover if you have a NAND, eMMC or eMCP chip looking on the board are reading the signature on the flash memory chip.
The Multitool (see later) also can detect which chip you have onboard: the program will warn you at startup if you have a NAND chip.
 
NAND bootloader upgrade:
IMPORTANT: don't do this is you have an eMMC or eMCP; skip this paragraph if you are unsure too!
For very expert people who are having issues when (re)booting images, there is the chance to upgrade the bootloader on NAND.
The NAND bootloader is nothing else than a regular idbloader (see official rockchip documentation) but contains some bits to correctly access the data on your flash memory.
Upgrading requires to erase the existing flash content, in the worst case will require you to follow the Unbrick procedure above or restore an older but more compatible bootloader.
If you are not mentally ready to overcome possible further issues, don't do this!
 
The detailed instructions and the binaries are available at this post
 
Multimedia:
Mainline kernel: 3D acceleration is provided by Lima driver and is already enabled. Hardware video decoding: https://forum.armbian.com/topic/19258-testing-hardware-video-decoding-rockchip-allwinner/ Deprecated legacy kernel: multimedia features, like OpenGL/OpenGL ES acceleration, hardware accelerated Kodi, ffmpeg and mpv you can take a look to this post An effective tutorial from @Hai Nguyen on how to configure a box as a hi-quality music player using an USB audio card, and controlling it via remote control is available in this post  
Brief explanation about kernel naming:
current kernel is the mainline LTS kernel version, most maintained and tested. This is the suggested version for production devices. If you don't know what to pick, pick this. legacy kernel (version 4.4) is provided by manufacturer; it is deprecated, unmaintained and not suggested. edge kernel is the development mainline kernel version, with experimental features and drivers; usually stable but perhaps suitable for production devices.  
You can switch from one kernel flavour to another using armbian-config or manually via apt.
 
Installation (via SD card):
Building:
You can build your own image follow the common steps to build armbian for other tv boxes devices: when you are in the moment to choose the target board, switch to CSC/TVB/EOL boards and select "rk322x-box" from the list.
 
Download prebuilt images from the following links:
Archive builds (GPG-signed) - https://imola.armbian.com/dl/rk322x-box/archive/ SUGGESTED - Nightly built from trunk each week by Armbian servers (GPG-signed) - https://github.com/armbian/community Old images provided by me (unsigned and outdated) - https://users.armbian.com/jock/rk322x/armbian/stable  
Archived/older images:
https://armbian.hosthatch.com/archive/rk322x-box/archive/
 
Multitool:
The Multitool is a small but powerful tool to do quick backup/restore of internal flash, but also burn images and general system rescue and maintenance via terminal or SSH.
Compressed images will be uncompressed on fly.
Multitool - A small but powerful image for RK322x TV Box maintenance (instructions to access via network here)  
Quick installation instructions on eMMC:
Build or download your preferred Armbian image and a copy of the Multitool; Burn the Multitool on an SD card; once done, place the Armbian image in images folder of the SD card NTFS partition; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; OPTIONAL: you can do a backup of the existing firmware with "Backup flash" menu option; Choose "Burn image to flash" from the menu, then select the destination device (usually mmcblk2) and the image to burn; Wait for the process to complete, then choose "Shutdown" from main menu; Unplug the power cord and the SD card, then replug the power cord; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt. On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run sudo rk322x-config and select your board characteristics to enable leds, wifi chips, high-speed eMMC, etc... Run sudo armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed and configured!  
Despite the procedure above is simple and reliable, I always recommend to first test that your device boots Armbian images from SD Card.
Due to the really large hardware variety, there is the rare chance that the images proposed here may not boot. If a bad image is burned in eMMC, the box may not boot anymore forcing you to follow the unbrick section at the top of this post.
 
Quick installation instructions on NAND:
Build or download your preferred Armbian image and a copy of the Multitool; Burn the Multitool on an SD card; once done, place the Armbian legacy kernel image in images folder of the SD card NTFS partition; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; OPTIONAL: you can do a backup of the existing firmware with "Backup flash" menu option; Choose "Burn Armbian image via steP-nand" from the menu, then select the destination device (usually rknand0) and the image to burn; Wait for the process to complete, then choose "Shutdown" from main menu; Unplug the power cord and the SD card, then replug the power cord; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt. On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run sudo rk322x-config and select your board characteristics to enable leds, wifi chips, etc... Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed!  
Alternative: you can install the bootloader in NAND and let it boot from SD Card or USB:
Download a copy of the Multitool and burn it on an SD card; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; RECOMMENDED: make a backup of the existing firmware with "Backup flash" menu option; Choose "Install Jump Start for Armbian" menu option: the Jump Start uses the internal NAND to boot from external SD Card or external USB Stick; Follow the general instructions to boot from SD Card below, skip the first erase eMMC step.  
Quick installation instructions to boot from SD Card:
If you are already running Armbian from eMMC, skip to the next step. Instead if you are running the original firmware you need to first erase the internal eMMC; to do so download the Multitool, burn it on an SD Card, plug the SD Card and power the TV Box. Use "Backup flash" if you want to do a backup of the existing firmware, then choose "Erase flash" menu option. Build or download your preferred Armbian image; Uncompress and burn the Armbian image on the SD Card; Plug the SD Card in the TV Box and power it on; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run sudo rk322x-config and select your board characteristics to enable leds, wifi chips, high-speed eMMC or NAND, etc... Run armbian-config to configure timezone, locales and other personal options, or also to transfer the SD Card installation to internal eMMC; Congratulations, Armbian is running from SD Card!  
A note about boot device order:
With Armbian also comes mainline U-boot. If you install Armbian or just the bootloader in the eMMC or the Jump Start on internal NAND, the bootloader will look for valid bootable images in this order:
External SD Card External USB Stick in OTG Port Internal eMMC  
Installation (without SD card, board with eMMC)
If you have no sd card slot and your board has an eMMC, you can burn the armbian image directly on the internal eMMC using rkdeveloptool and a male-to-male USB cable:
 
Download your preferred Armbian image from Armbian download page and decompress it. Download the rk322x bootloader: rk322x_loader_v1.10.238_256.bin Download a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. Unplug the power cord from the tv box Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors) while pressing the reset microbutton with a toothpick. You can find the reset microbutton in a hole in the back of the box, but sometimes it is hidden into the AV analog jack Plug the other end of the USB Male-to-male cable into an USB port of your computer If everything went well, run lsusb: you should see a device with ID 2207:320b Run sudo rkdeveloptool rd 3 (if this fails don't worry and proceed to next step) Run sudo rkdeveloptool db rk322x_loader_v1.10.238_256.bin Run sudo rkdeveloptool wl 0x0 image.img (change image.img this with the real Armbian image filename) Unplug the power cord Done!  
Installation (without SD card, board with NAND)
If you are in the unfortunate case you can't use an SD card for installation and your board has a NAND chip, you still have an option to use the quick Multitool installation steps via USB.
 
Obtain a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. Unplug the power cord from the tv box Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors) while pressing the reset microbutton with a toothpick. You can find the reset microbutton in a hole in the back of the box, but sometimes it is hidden into the AV analog jack Plug the other end of the USB Male-to-male cable into an USB port of your computer If everyting went well, using lsusb you should see a device with ID 2207:320b Run sudo rkdeveloptool wl 0x4000 u-boot-main.img (download u-boot-main.img.xz , don't forget to decompress it!) Unplug the power cord  
Now you can follow the instructions on how to install on eMMC/NAND via SD card, just use instead an USB stick to do all the operations and plug it into the USB OTG port. Once you reboot, USB OTG port will be used as a boot device.
 
NOTE: NAND users without SD slot may be unhappy to know that it will be difficult to do extra maintenance with Multitool in case something breaks in the installed Armbian system: installing u-boot-main.img makes the installed system unbootable because it is missing the NAND driver.
 
 
Alternative backup, restore and erase flash for EXPERTS:
These backup, restore and erase flash procedures are for experts only. They are kept here mostly for reference, since the Multitool is perfectly able to do same from a very comfy interface and is the suggested way to do maintenance.
 
Backup:
Obtain a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. If you prefer, you can compile it yourself from the sources available at official rockchip repository Unplug the power cord from the tv box Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors) while pressing the reset microbutton with a toothpick. You can find the reset microbutton in a hole in the back of the box, but sometimes it is hidden into the AV analog jack Plug the other end of the USB Male-to-male cable into an USB port of your computer If everyting went well, using lsusb you should see a device with ID 2207:320b change directory and move into rkbin/tools directory, run ./rkdeveloptool rfi then take note of the FLASH SIZE megabytes (my eMMC is 8Gb, rkdeveloptool reports 7393 megabytes) run ./rkdeveloptool rl 0x0 $((FLASH_SIZE * 2048)) backup.data (change FLASH_SIZE with the value you obtained the step before) once done, the internal eMMC is backed up to backup.data file  
Restore: first we have to restore the original bootloader, then restore the original firmware.
Running rkdeveloptool with these switches will accomplish both the jobs:
./rkdeveloptool db rk322x_loader_v1.10.238_256.bin Downloading bootloader succeeded. ./rkdeveloptool ul rk322x_loader_v1.10.238_256.bin Upgrading loader succeeded. ./rkdeveloptool wl 0x0 backup.data Write LBA from file (100%) Download here:
 
Erase the flash memory: clearing the internal eMMC/NAND memory makes the SoC look for external SD Card as first boot option.
If there isn't any suitable SD Card, the SoC enters maskrom mode, which can then be used for full eMMC/NAND access using rkdeveloptool. This is perfectly fine if your box has an eMMC flash memory.
NOTE: In case you have a NAND flash memory this option is however discouraged. The original bootloader contains some special parameters to correctly access the data. Clearing the flash memory will probably garbage the NAND data and restoring the bootloader may require some special instructions.
 
Obtain a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. If you prefer, you can compile it yourself from the sources available at official rockchip repository Unplug the power cord from the board Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors) while pressing the reset microbutton with a toothpick. You can find the reset microbutton in a hole in the back of the box, but sometimes it is hidden into the AV analog jack Plug the other end of the USB Male-to-male cable into an USB port of your computer If everyting went well, using lsusb you should see a device with ID 2207:320b run ./rkdeveloptool ef and wait a few seconds once done, the internal eMMC is erased and the device will boot from the sdcard from now on  
Partecipation and debugging:
If you want to partecipate or need help debugging issues, do not hesitate to share your experience with the installation procedure of the boxes.
In case of issues and missed support, provide as many as possible of these things is very useful to try and bring support for an unsupported board:
 
some photos of both sides of the board. Details of the eMMC, DDR and Wifi chips are very useful! upload the device tree binary (dtb) of your device. We can understand a lot of things of the hardware from that small piece of data; and alternative is a link to the original firmware (you can do a full backup with the Multitool); dmesg and other logs (use armbianmonitor -u that automatically collects and uploads the logs online) attach a serial converter to the device and provide the output of the serial port;  
Critics, suggestions and contributions are welcome!
 
Credits:
@fabiobassa for his ideas, inspiration, great generosity in giving the boards for development and testing. The project of bringing rk322x into armbian would not have begun without his support! Justin Swartz, for his work and research to bring mainline linux on rk3229 (repository here) @knaerzche for his great contribution to libreelec support and mainline patches @Alex83 for his patience in testing the NAND bootloader upgrade procedure on his board @Jason Duhamell for his generous donation that allowed researching eMCP boards and esp8089 wifi chip

@ochentay4 I set up a multitool image with the same fix proposed by @ilmich on his libreelec image. This fresh build is totally untested, but you can download a copy from here and test by yourself. Perhaps this solves @n3o problem too.

@desperex You would have to ask Orange PI that question, as that is their name for their board.

@desperex Armbian doesn't have the resources to track bugs and work for fixes in upstream code.  We generally just take upstream code and incorporate.  So someone external to Armbian needs to work the upstream producers to get them to make fixes as appropriate.  The problem is that for many of these inexpensive commodity chips/drivers there isn't any long term support infrastructure (i.e. they produce, release and then move on to the next chip with no intention to support them)

NAND are not exactly easy beasts, if the multitool does not detect it anymore it is because the kernel rockchip driver does not detect it.
It is difficult to say what happened exactly, we have spent hours and hours to figure out what was the behaviour of the nand driver and all the other proprietary software pieces of the puzzle.
Also they are quite "fragile" pieces of hardware, and abusing of them can quickly destroy the cells capacity to work.
 
In the past, people has restored the NAND functionality restoring original android images with AndroidTool for windows, or uploading particular bootloaders; you should look for such resources in this thread (or with google) because some procedures were described to do so I forgot to bookmark.
 
For what me and @fabiobassa have seen, what seems to be an apparently random behaviour of the NANDs, in reality it is deterministic and can be understood. What we've found to be totally confusing was the fact that keeping anything attached to the board (HDMI, ethernet, keyboard, serial adapter, ... whatever!) can prevent the NAND from being detected after a reboot.
 
Also remember to use the armbian image with the legacy kernel, those with mainline kernel miss the proprietary driver. Also you could post a dmesg log after booting such legacy kernel image to see what the driver has to say about NAND.
 

Great thanks for the archive of current version of armbian for rk3318  boxes !!
Now its possible installing one good working version that is not braking more time in the mouths and is getting current updates :-)))

https://imola.armbian.com/dl/rk3318-box/archive/

You can check the dpll core clock in linux, it tells you the clock used by the dram controller.
 
cat /sys/kernel/debug/clk/dpll/clk_rate  
It should tell you 666Mhz or 1333Mhz, I don't remember if it accounts for double-data rate or not (but I think not, probably will tell 666Mhz).
 
edit: about the poor youtube performance, it is due to the fact that the cpu is not powerful enough, there is no hardware video decoding yet for videos in the browser and the graphics pipeline is not really well optimized for general purpose desktop environments.

@pakos96 That's right, the flashing leds are made on purpose to have a visual feedback that the kernel is alive.
 
Once you setup the led-config suitable for your board, you can change the led behaviour writing to /sys/class/leds/working/trigger. You can even read that file to know which are the available triggers.

@MattWestB beware that rk3318-config does not let choose DDR frequency, that's for rk322x.
rk3318 requires proprietary trust os to enable the ddr scaling, but the proprietary os does not allow frequencies above 1.1ghz artificially crashing the system.
For this reason, on rk3318 I'm using the mainline opensource trust os, which allows to run the cpu above 1.1ghz without issues, but does not support ddr scaling.
 
That's it, closed source code 🙄

Tested OrangePi 4 LTS:
Armbian_23.02.1_Orangepi4-lts_jammy_current_5.15.93_xfce_desktop.img.xz Armbian_23.02.1_Orangepi4-lts_bullseye_current_5.15.93_minimal.img.xz Bluetooth adapter is detected, but this time I was unable to pair with the usual audio speaker
The rest seems to work pretty well

1. Checking the progress of Armbian-next
 
Video:
https://us06web.zoom.us/rec/share/ly7gbgZBTY1M4eiumUk6Gp357Jl0RV0h7usdUEGN5WcNKXNIwsOoNHbtoLbBeEje.KCku4wdAigfEI7pB
 
Armbian Next Jira:
https://armbian.atlassian.net/browse/AR-1451
 
@Contributor/Maintainer

@Dario Murgia Don't worry, it is not essential, it was just good to know. However the fix has been mainlined in armbian

thanks for having a look. 
 
anyhow, I have SPDIF working now (on kernel 5.15.90)!
 
digging a bit into the dts generated from your rk3318-box.dtb and the rk3328 datasheet, I realized there are three pins capable of being set as SPDIF-out
 
spdif-0 { spdifm0-tx { rockchip,pins = <0x00 0x1b 0x01 0x66>; phandle = <0x13>; }; }; spdif-1 { spdifm1-tx { rockchip,pins = <0x02 0x11 0x02 0x66>; phandle = <0xd8>; }; }; spdif-2 { spdifm2-tx { rockchip,pins = <0x00 0x02 0x02 0x66>; phandle = <0xd9>; }; };  
in your DTB the first one was selected, in the pinctrl-0 declaration
 
spdif@ff030000 { compatible = "rockchip,rk3328-spdif"; reg = <0x00 0xff030000 0x00 0x1000>; interrupts = <0x00 0x1d 0x04>; clocks = <0x02 0x2e 0x02 0x13a>; clock-names = "mclk\0hclk"; dmas = <0x12 0x0a>; dma-names = "tx"; pinctrl-names = "default"; pinctrl-0 = <0x13>; #sound-dai-cells = <0x00>; status = "okay"; phandle = <0x10>; };  
so I tried to replace 0x13 (corresponding to spdifm0) with 0xd8 (corresponding to spdifm1), rebuilt the DTB and then I had SPDIF up and running on my x88pro-10!
 
 

The trust os of the original firmware is very old, but yet I don't know the reason why the trust os from the multitool is acting weird. Unfortunately that piece of code is a closed binary blob and I don't know what it is actually doing.
 
I arranged another multitool with a different trust os. It is not guaranteed to work, but you may try: https://drive.google.com/file/d/1b0BOwdr0J6XxYDyn1HfprtmBPhMHIfnV/view?usp=share_link

DISCLAIMERS (PLEASE READ):
Everything you can find in this thread (binaries, texts, code snippets, etc...) are provided AS-IS and are not part of official Armbian project. For this reason not people from Armbian project nor myself are responsible for misuse or loss of functionality of hardware. THIS POST explains very well the troubles with TV Boxes and why they are not suitable for everyone Please don't ask about support or assistance in other non-community forums nor in the official Armbian github repository, instead post your questions in this thread, in the TV Boxes forum section (hardware related) or in the Peer-to-peer support section (general linux/software related).  
Following the recent thread on LibreElec forum about an unofficial image for rk3229 devices, I would like to make public the work made by me and @fabiobassa about bringing rk322x support to armbian.
The project is now in -> mainline Armbian <- development fork -> here <-
 
This first page and the last 3 or 4 pages of the thread are enough to get up to date with recent developments.
Many useful experiences are scattered through the thread, but the most important things are collected here in the first page, so please read it carefully!
 
Mainline kernel is fully supported and will receive most support in the future. Legacy kernel 4.4 is deprecated, but is kept around only for special purposes.
 
What works:
Should boot and work flawlessy on all boards with RK3228a, RK3228b and RK3229, with either DDR2 and DDR3 memories. Mainline u-boot Proprietary OPTEE provided as Trusted Execution Environment (needed for DRAM frequency scaling) All 4 cores are working Ethernet Serial UART (configured at 115200 bps, not 1.5Mbps!) Thermals, CPU and DRAM frequency scaling OTG USB 2.0 port (also as boot device!) EHCI/OHCI USB 2.0 ports MMC subsystem (including eMMC, SD and sdio devices) Hardware video acceleration NAND is available only on legacy kernel. To fully boot from NAND, use the Multitool and its steP-nand installation (instructions are below) Various WIFI over SDIO are supported (SSV6051P, SSV6256P, ESP8089, Realtek chips, etc...), ssv6256p driver is available only on legacy kernel Full GPU acceleration U-boot boot order priority: first the sdcard, then the USB OTG port and eventually the internal eMMC; you can install u-boot (and the whole system) in the internal eMMC and u-boot will always check for images on external sdcard/USB first.  
Unbrick:
Technically, rockchip devices cannot be bricked. If the internal flash does not contain a bootable system, they will always boot from the sdcard. If, for a reason, the bootable system on the internal flash is corrupted or is unable to boot correctly, you can always force the maskrom mode shorting the eMMC clock pin on the PCB. Here there is the procedure, but you can also google around if you get stuck on a faulty bootloader, the technique is pretty simple and requires a simple screwdriver.
 
There are however some unfortunate cases (expecially newer boards) where shorting the eMMC clock pin is difficult or impossibile, like eMMC or eMCP BGA chips with no exposed pins. In those cases pay double attention when burning something on the internal eMMC/eMCP and always test first the image from the sdcard to be sure it works before burning anything on eMMC/eMCP.
 
Some useful links with pins, pads or procedures for some boards:
Generic procedure for boards with non-BGA eMMC MXQPRO_V71 - eMCP H20 - eMCP ZQ01 - eMCP  
NAND vs eMMC vs eMCP difference:
RK3228 and RK3229 tv boxes comes with three different flash memory chips: eMMC, NAND and eMCP.
It does not depend upon the market name of the tv box and neither the internal board; manufacturers put whatever they find cheaper when they buy the components.
 
NAND chip is just the non-volatile memory eMMC chip contains both the non-volatile memory plus a controller. eMCP chip contains the non-volatile memory, a controller for the non-volatile memory (like eMMC), but also contains a bank of DDR SDRAM memory on the same physical chip.  
The difference is very important, because eMMC and eMCP are far easier to support at various levels: the controller deals with the physical characteristics of the non-volatile memory, so the software has no to deal with.
NAND chips instead are harder to support, because the software is required to deal with the physical characteristics and non-standard things that depends upon the NAND manufacturer.
 
If you have a NAND chips you're unlucky because mainline kernel currently cannot access it, but also because you need special care and instructions explained later.
 
You can discover if you have a NAND, eMMC or eMCP chip looking on the board are reading the signature on the flash memory chip.
The Multitool (see later) also can detect which chip you have onboard: the program will warn you at startup if you have a NAND chip.
 
NAND bootloader upgrade:
IMPORTANT: don't do this is you have an eMMC or eMCP; skip this paragraph if you are unsure too!
For very expert people who are having issues when (re)booting images, there is the chance to upgrade the bootloader on NAND.
The NAND bootloader is nothing else than a regular idbloader (see official rockchip documentation) but contains some bits to correctly access the data on your flash memory.
Upgrading requires to erase the existing flash content, in the worst case will require you to follow the Unbrick procedure above or restore an older but more compatible bootloader.
If you are not mentally ready to overcome possible further issues, don't do this!
 
The detailed instructions and the binaries are available at this post
 
Multimedia:
Mainline kernel: 3D acceleration is provided by Lima driver and is already enabled. Hardware video decoding: https://forum.armbian.com/topic/19258-testing-hardware-video-decoding-rockchip-allwinner/ Deprecated legacy kernel: multimedia features, like OpenGL/OpenGL ES acceleration, hardware accelerated Kodi, ffmpeg and mpv you can take a look to this post An effective tutorial from @Hai Nguyen on how to configure a box as a hi-quality music player using an USB audio card, and controlling it via remote control is available in this post  
Brief explanation about kernel naming:
current kernel is the mainline LTS kernel version, most maintained and tested. This is the suggested version for production devices. If you don't know what to pick, pick this. legacy kernel (version 4.4) is provided by manufacturer; it is deprecated, unmaintained and not suggested. edge kernel is the development mainline kernel version, with experimental features and drivers; usually stable but perhaps suitable for production devices.  
You can switch from one kernel flavour to another using armbian-config or manually via apt.
 
Installation (via SD card):
Building:
You can build your own image follow the common steps to build armbian for other tv boxes devices: when you are in the moment to choose the target board, switch to CSC/TVB/EOL boards and select "rk322x-box" from the list.
 
Download prebuilt images from the following links:
Archive builds (GPG-signed) - https://imola.armbian.com/dl/rk322x-box/archive/ SUGGESTED - Nightly built from trunk each week by Armbian servers (GPG-signed) - https://github.com/armbian/community Old images provided by me (unsigned and outdated) - https://users.armbian.com/jock/rk322x/armbian/stable  
Archived/older images:
https://armbian.hosthatch.com/archive/rk322x-box/archive/
 
Multitool:
The Multitool is a small but powerful tool to do quick backup/restore of internal flash, but also burn images and general system rescue and maintenance via terminal or SSH.
Compressed images will be uncompressed on fly.
Multitool - A small but powerful image for RK322x TV Box maintenance (instructions to access via network here)  
Quick installation instructions on eMMC:
Build or download your preferred Armbian image and a copy of the Multitool; Burn the Multitool on an SD card; once done, place the Armbian image in images folder of the SD card NTFS partition; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; OPTIONAL: you can do a backup of the existing firmware with "Backup flash" menu option; Choose "Burn image to flash" from the menu, then select the destination device (usually mmcblk2) and the image to burn; Wait for the process to complete, then choose "Shutdown" from main menu; Unplug the power cord and the SD card, then replug the power cord; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt. On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run sudo rk322x-config and select your board characteristics to enable leds, wifi chips, high-speed eMMC, etc... Run sudo armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed and configured!  
Despite the procedure above is simple and reliable, I always recommend to first test that your device boots Armbian images from SD Card.
Due to the really large hardware variety, there is the rare chance that the images proposed here may not boot. If a bad image is burned in eMMC, the box may not boot anymore forcing you to follow the unbrick section at the top of this post.
 
Quick installation instructions on NAND:
Build or download your preferred Armbian image and a copy of the Multitool; Burn the Multitool on an SD card; once done, place the Armbian legacy kernel image in images folder of the SD card NTFS partition; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; OPTIONAL: you can do a backup of the existing firmware with "Backup flash" menu option; Choose "Burn Armbian image via steP-nand" from the menu, then select the destination device (usually rknand0) and the image to burn; Wait for the process to complete, then choose "Shutdown" from main menu; Unplug the power cord and the SD card, then replug the power cord; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt. On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run sudo rk322x-config and select your board characteristics to enable leds, wifi chips, etc... Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed!  
Alternative: you can install the bootloader in NAND and let it boot from SD Card or USB:
Download a copy of the Multitool and burn it on an SD card; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; RECOMMENDED: make a backup of the existing firmware with "Backup flash" menu option; Choose "Install Jump Start for Armbian" menu option: the Jump Start uses the internal NAND to boot from external SD Card or external USB Stick; Follow the general instructions to boot from SD Card below, skip the first erase eMMC step.  
Quick installation instructions to boot from SD Card:
If you are already running Armbian from eMMC, skip to the next step. Instead if you are running the original firmware you need to first erase the internal eMMC; to do so download the Multitool, burn it on an SD Card, plug the SD Card and power the TV Box. Use "Backup flash" if you want to do a backup of the existing firmware, then choose "Erase flash" menu option. Build or download your preferred Armbian image; Uncompress and burn the Armbian image on the SD Card; Plug the SD Card in the TV Box and power it on; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run sudo rk322x-config and select your board characteristics to enable leds, wifi chips, high-speed eMMC or NAND, etc... Run armbian-config to configure timezone, locales and other personal options, or also to transfer the SD Card installation to internal eMMC; Congratulations, Armbian is running from SD Card!  
A note about boot device order:
With Armbian also comes mainline U-boot. If you install Armbian or just the bootloader in the eMMC or the Jump Start on internal NAND, the bootloader will look for valid bootable images in this order:
External SD Card External USB Stick in OTG Port Internal eMMC  
Installation (without SD card, board with eMMC)
If you have no sd card slot and your board has an eMMC, you can burn the armbian image directly on the internal eMMC using rkdeveloptool and a male-to-male USB cable:
 
Download your preferred Armbian image from Armbian download page and decompress it. Download the rk322x bootloader: rk322x_loader_v1.10.238_256.bin Download a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. Unplug the power cord from the tv box Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors) while pressing the reset microbutton with a toothpick. You can find the reset microbutton in a hole in the back of the box, but sometimes it is hidden into the AV analog jack Plug the other end of the USB Male-to-male cable into an USB port of your computer If everything went well, run lsusb: you should see a device with ID 2207:320b Run sudo rkdeveloptool rd 3 (if this fails don't worry and proceed to next step) Run sudo rkdeveloptool db rk322x_loader_v1.10.238_256.bin Run sudo rkdeveloptool wl 0x0 image.img (change image.img this with the real Armbian image filename) Unplug the power cord Done!  
Installation (without SD card, board with NAND)
If you are in the unfortunate case you can't use an SD card for installation and your board has a NAND chip, you still have an option to use the quick Multitool installation steps via USB.
 
Obtain a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. Unplug the power cord from the tv box Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors) while pressing the reset microbutton with a toothpick. You can find the reset microbutton in a hole in the back of the box, but sometimes it is hidden into the AV analog jack Plug the other end of the USB Male-to-male cable into an USB port of your computer If everyting went well, using lsusb you should see a device with ID 2207:320b Run sudo rkdeveloptool wl 0x4000 u-boot-main.img (download u-boot-main.img.xz , don't forget to decompress it!) Unplug the power cord  
Now you can follow the instructions on how to install on eMMC/NAND via SD card, just use instead an USB stick to do all the operations and plug it into the USB OTG port. Once you reboot, USB OTG port will be used as a boot device.
 
NOTE: NAND users without SD slot may be unhappy to know that it will be difficult to do extra maintenance with Multitool in case something breaks in the installed Armbian system: installing u-boot-main.img makes the installed system unbootable because it is missing the NAND driver.
 
 
Alternative backup, restore and erase flash for EXPERTS:
These backup, restore and erase flash procedures are for experts only. They are kept here mostly for reference, since the Multitool is perfectly able to do same from a very comfy interface and is the suggested way to do maintenance.
 
Backup:
Obtain a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. If you prefer, you can compile it yourself from the sources available at official rockchip repository Unplug the power cord from the tv box Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors) while pressing the reset microbutton with a toothpick. You can find the reset microbutton in a hole in the back of the box, but sometimes it is hidden into the AV analog jack Plug the other end of the USB Male-to-male cable into an USB port of your computer If everyting went well, using lsusb you should see a device with ID 2207:320b change directory and move into rkbin/tools directory, run ./rkdeveloptool rfi then take note of the FLASH SIZE megabytes (my eMMC is 8Gb, rkdeveloptool reports 7393 megabytes) run ./rkdeveloptool rl 0x0 $((FLASH_SIZE * 2048)) backup.data (change FLASH_SIZE with the value you obtained the step before) once done, the internal eMMC is backed up to backup.data file  
Restore: first we have to restore the original bootloader, then restore the original firmware.
Running rkdeveloptool with these switches will accomplish both the jobs:
./rkdeveloptool db rk322x_loader_v1.10.238_256.bin Downloading bootloader succeeded. ./rkdeveloptool ul rk322x_loader_v1.10.238_256.bin Upgrading loader succeeded. ./rkdeveloptool wl 0x0 backup.data Write LBA from file (100%) Download here:
 
Erase the flash memory: clearing the internal eMMC/NAND memory makes the SoC look for external SD Card as first boot option.
If there isn't any suitable SD Card, the SoC enters maskrom mode, which can then be used for full eMMC/NAND access using rkdeveloptool. This is perfectly fine if your box has an eMMC flash memory.
NOTE: In case you have a NAND flash memory this option is however discouraged. The original bootloader contains some special parameters to correctly access the data. Clearing the flash memory will probably garbage the NAND data and restoring the bootloader may require some special instructions.
 
Obtain a copy of rkdeveloptool: a compiled binary is available in the official rockchip-linux rkbin github repository. If you prefer, you can compile it yourself from the sources available at official rockchip repository Unplug the power cord from the board Plug an end of an USB Male-to-male cable into the OTG port (normally it is the lone USB port on the same side of the Ethernet, HDMI, analog AV connectors) while pressing the reset microbutton with a toothpick. You can find the reset microbutton in a hole in the back of the box, but sometimes it is hidden into the AV analog jack Plug the other end of the USB Male-to-male cable into an USB port of your computer If everyting went well, using lsusb you should see a device with ID 2207:320b run ./rkdeveloptool ef and wait a few seconds once done, the internal eMMC is erased and the device will boot from the sdcard from now on  
Partecipation and debugging:
If you want to partecipate or need help debugging issues, do not hesitate to share your experience with the installation procedure of the boxes.
In case of issues and missed support, provide as many as possible of these things is very useful to try and bring support for an unsupported board:
 
some photos of both sides of the board. Details of the eMMC, DDR and Wifi chips are very useful! upload the device tree binary (dtb) of your device. We can understand a lot of things of the hardware from that small piece of data; and alternative is a link to the original firmware (you can do a full backup with the Multitool); dmesg and other logs (use armbianmonitor -u that automatically collects and uploads the logs online) attach a serial converter to the device and provide the output of the serial port;  
Critics, suggestions and contributions are welcome!
 
Credits:
@fabiobassa for his ideas, inspiration, great generosity in giving the boards for development and testing. The project of bringing rk322x into armbian would not have begun without his support! Justin Swartz, for his work and research to bring mainline linux on rk3229 (repository here) @knaerzche for his great contribution to libreelec support and mainline patches @Alex83 for his patience in testing the NAND bootloader upgrade procedure on his board @Jason Duhamell for his generous donation that allowed researching eMCP boards and esp8089 wifi chip

The trust os of the original firmware is very old, but yet I don't know the reason why the trust os from the multitool is acting weird. Unfortunately that piece of code is a closed binary blob and I don't know what it is actually doing.
 
I arranged another multitool with a different trust os. It is not guaranteed to work, but you may try: https://drive.google.com/file/d/1b0BOwdr0J6XxYDyn1HfprtmBPhMHIfnV/view?usp=share_link

This is log when run only Android, without sd card with Multitool
New Text Document (3).txt