SteeMan

TV Box Name: OSMC Vero 4k
CPU: Amlogic S905X
Armbian build file name:
Armbian_community_25.5.0-trunk.301_Aml-s9xx-box_bookworm_current_6.12.20_minimal.img Armbian_community_25.5.0-trunk.301_Aml-s9xx-box_bookworm_current_6.12.20_xfce_desktop.img DTB file used: meson-gxl-s905x-vero4k.dtb
U-Boot used: u-boot-s905x-s912
Kernel Version: 6.12.20
Distribution Installed: bookworm
Working Ethernet: Yes
Max Ethernet Speed that works: 100Mbps
Does wifi work: No
Does bluetooth work: Yes
Does HDMI audio work: No
Additional Comments (provide any additional information you feel is important):
 
WARNING: RISK OF BRICKING! Only proceed if you know what you're doing and are willing to accept the risk of bricking your device!
 
If your use case doesn't require Armbian or the latest Linux kernel, you may want to try these solutions first:
Run `systemctl disable mediacenter` from the OSMC terminal and continue from there Simple X11 desktop: https://discourse.osmc.tv/t/testing-x11-simple-desktop-chromium-web-browser-in-a-simple-installer-for-stretch/16846 Headless arm64 Docker: https://discourse.osmc.tv/t/non-official-headless-arm64-docker-solution-for-vero4k/108666/4  
Toothpick method doesn't boot Armbian, because standard u-boot config expects kernel.img and dtb.img to be present in a different file format than Armbian provides.
Getting Armbian to boot requires changing the u-boot environment to the one provided by aml_autoscript. This can be done from a working OSMC installation or recovery.
The method below ensures you can still boot the original OSMC installation by removing the SD card.
 
Prerequisites:
Terminal skills and patience Vero 4k with working OSMC installation (https://osmc.tv/wiki/vero-4k/reinstalling-osmc/) USB keyboard and HDMI monitor attached to Vero High quality micro SD card PC with SD card reader Toothpick or similar (non-conducting)  
SD card preparation:
Download latest image: https://www.armbian.com/amlogic-s9xx-tv-box/ Write image to SD card as described in this post: https://forum.armbian.com/topic/33676-installation-instructions-for-tv-boxes-with-amlogic-cpus/  
Let's get dangerous! To change the u-boot configuration on the Vero 4k:
Boot Vero into recovery by applying power and holding the (left) shift button. This might take a few tries The device should prompt a tty screen. Login with user osmc and password osmc Run the following commands (these are from the aml_autoscript file in the Armbian /boot partition):  
IMPORTANT: Make sure these lines are exactly correct, because if not it can mess up the boot process and brick your device!
fw_setenv bootcmd 'run start_autoscript; run osmcfromsd; run osmcfromusb; run storeboot' fw_setenv start_autoscript 'if mmcinfo; then run start_mmc_autoscript; fi; if usb start; then run start_usb_autoscript; fi; run start_emmc_autoscript' fw_setenv start_emmc_autoscript 'if fatload mmc 1 1020000 emmc_autoscript; then autoscr 1020000; fi;' fw_setenv start_mmc_autoscript 'if fatload mmc 0 1020000 s905_autoscript; then autoscr 1020000; fi;' fw_setenv start_usb_autoscript 'for usbdev in 0 1 2 3; do if fatload usb ${usbdev} 1020000 s905_autoscript; then autoscr 1020000; fi; done'  
To verify, run `fw_printenv | grep bootcmd` etc.  
The fun part: boot into Armbian
Power off the device: execute `poweroff` command, wait until device light is red and remove power. Insert the Armbian SD card into the Vero 4k. It should go in upside down and all the way until you hear a slight click sound. Apply power again After some u-boot and kernel logs the device should show the Armbian boot up screen Enjoy Armbian on your Vero 4k! Removing the SD card should boot into OSMC from eMMC again.  
Many thanks to @SteeMan for helping me with the original troubleshooting here: https://forum.armbian.com/topic/49733-installing-armbian-on-vero-4k-does-not-boot-from-sd-card
 
Hardware video acceleration, HDMI audio and WiFi don't seem to work out of the box, but I can imagine that with some effort it's possible.
 

It worked! The Vero just booted into Armbian, thanks so much! 🎉 🙏

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

I was able to finally boot propperly into the emmc via UART commands.

Now the question is.... how do i make it so it boots from SD  (if present)  or EMMC  automatically
 
 

 

This design decision has been around from the early days of Armbian and SBC's.  If you think about Armbian as a firmware for your board instead of a general operating system like on your PC, that makes some sense as to why originally that would have made the most sense (you install new firmwares, you don't upgrade them in place).  Also, all those early boards were limited on the amount of internal emmc storage they may have had, if any, and SD cards were also much smaller in storage capacity at that time.  So wasting space with an entire extra kernel wasn't really an option.
 
Now move forward 10 years and most of those limitations are lessened.  So it could be supported today for most build targets.  But the current approach would likely still be needed for some boards.  So while it would be feasible to support having multiple kernels installed it would take a lot of effort to implement (across all the different booting scenarios, u-boot scripts, extlinux, uefi, etc).  Also in many of these scenarios it doesn't really help as you need an interactive boot (i.e. with hdmi and keyboard/mouse input) to present a menu to the user to select an alternate boot target, and that interactive boot environment isn't common on SBC's (unlike the PC world).  If you have to solder and hookup a USB-UART connector to monitor the debug output to be able to switch your boot kernel, is that better/easier then just popping in a different SD card?
 
So ultimately like a lot in the open source world, this change while possible, hasn't attracted the interest/need for any developer out there to want to undertake this effort.  Which leads me to the inevitable next comment, PRs are always welcome for contributions to the project 🙂
 
(Personally this is something I would also like to see, but in looking into the effort it would take, I know I personally don't have the time to implement, and the workarounds are good enough for me)

This design decision has been around from the early days of Armbian and SBC's.  If you think about Armbian as a firmware for your board instead of a general operating system like on your PC, that makes some sense as to why originally that would have made the most sense (you install new firmwares, you don't upgrade them in place).  Also, all those early boards were limited on the amount of internal emmc storage they may have had, if any, and SD cards were also much smaller in storage capacity at that time.  So wasting space with an entire extra kernel wasn't really an option.
 
Now move forward 10 years and most of those limitations are lessened.  So it could be supported today for most build targets.  But the current approach would likely still be needed for some boards.  So while it would be feasible to support having multiple kernels installed it would take a lot of effort to implement (across all the different booting scenarios, u-boot scripts, extlinux, uefi, etc).  Also in many of these scenarios it doesn't really help as you need an interactive boot (i.e. with hdmi and keyboard/mouse input) to present a menu to the user to select an alternate boot target, and that interactive boot environment isn't common on SBC's (unlike the PC world).  If you have to solder and hookup a USB-UART connector to monitor the debug output to be able to switch your boot kernel, is that better/easier then just popping in a different SD card?
 
So ultimately like a lot in the open source world, this change while possible, hasn't attracted the interest/need for any developer out there to want to undertake this effort.  Which leads me to the inevitable next comment, PRs are always welcome for contributions to the project 🙂
 
(Personally this is something I would also like to see, but in looking into the effort it would take, I know I personally don't have the time to implement, and the workarounds are good enough for me)

@Joshua allen
 
asking for private chat to solve personal issues  is the most unappropriate way to act in a public forum.
 
For several reasons:

1) your problem could be the same problem for other people sharing your issues, so solving for you could be solving for many
2) this is an hobby for us and not job.     Job is paid, hobby is for free.          if you need help for your personal issue you can give an advice asking for paid help
3)this really is the worst approach to an open community of people that friendly and mutual try to help each others
 
that said....
would you share what is your problem, since you already asked for help ( private help..) in another post ?

describe what is working, what not, attach procedures and photos of board , explain your moves and results
 
We will try to give you a helpful  hand.

Please read this first:
 

These instructions are for Amlogic CPUs for TV Boxes. 
 
Note: If you have previously run other distributions on the box such as coreelec the below installation will not work.  You will need to restore the original android firmware before attempting the install.  coreelec changes the boot environment in ways that are incompatible with these Armbian builds.
 
Download links:
    Weekly Community Rolling Builds:  https://www.armbian.com/amlogic-s9xx-tv-box/
    or build your own image using the Armbian build framework
 
Once you download your chosen build, you need to burn the image to an SD card.  Generally balenaEtcher is recommended as it does a verification of the burn.  Also be sure to use high quality SD cards.
 
Once you have the SD card with your chosen build, then you need to edit the boot configuration file on the SD card.  In the BOOT partition of the SD card there will be a file /boot/extlinux/extlinux.conf, that you need to edit.  There will also be a extlinux.conf.template file to use as a reference.  You will need to add a line into the extlinux.conf file for the Device Tree (dtb) file you will be using for your box.  Place this line before the APPEND line as shown in the .template file.
 
Basically you need to have the correct dtb for your box.  You may need to attempt to use different dtb files until you find the one that works the best for your box's hardware (there are a bunch of dtb files in /boot/dtb/amlogic/... to try depending on your cpu architecture and hardware).  It is unlikely that there will be a matching dtb file for your TV box.  The idea is to find the one that works best for your box.  This may mean that you try booting with different dtb files until you fine one that works good enough for your needs.  By searching the forums you will find information about what dtbs other users have found work best for different boxes.  Because you are booting from an SD card, you can easily try different dtb files.  The dtd files are named by cpu family.  So for example dtb files for the s905x2 cpu are named meson-g12a-*.  Below there is a table that shows the identifiers for each familiy (g12a for s905x2 in this case).
 
Next you need to copy the correct uboot for your box.  This is needed for how these builds boot on amlogic boxes.  There are four different u-boot files located in the /boot directory:  u-boot-s905, u-boot-s905x-s912, u-boot-s905x2-s922, u-boot-s905x3
You need to copy (note copy not move) the u-boot file that matches your cpu to a new file named u-boot.ext in the /boot directory
So for example with a TX3 mini box that has an s905w cpu you would copy u-boot-s905x-s912 to u-boot.ext: cp u-boot-s905x-s912 u-boot.ext
(See table below for more details on which u-boot to use for which cpu)
 
Once you have your SD card prepared you need to enable multiboot on the box.  There are different ways documented to do this, but the most common is the "toothpick" method.  The "toothpick" method means to hold the reset button while applying power to the box.  The reset button is often hidden and located at the back of the audio/video jack connector.  By pressing that button with a toothpick or other such pointed device you can enable multiboot.  What you need to do is have the box unplugged, have your prepared sd card inserted, then press and hold the button while inserting the power connector.  Then after a bit of time you can release the button.  (I don't know exactly how long you need to hold the button after power is applied, but if it doesn't work the first time try again holding for longer or shorter times).
 
You should now be booting into armbian/linux.  Note that the first boot takes longer as it is enlarging the root filesystem to utilize the entire SD card.
 
After you are satisfied that your box is working correctly for your needs you can optionally copy the installation from the SD card to internal emmc storage (assuming your box has emmc). (Note: Installing to emmc has some risks of bricking your box.  Don't do this unless you feel you understand how to reinstall your box's android firmware)  You install armbian to emmc by running the shell script in the /root directory: install-aml.sh. Note: It is not possible to install into emmc on boxes with the s905 cpu (s905x, s905w, s905x2, etc however should all be supported).  It is recommended that you make a backup of emmc first.  Also be prepared if anything goes horribly wrong with your emmc install to reinstall the android firmware using the Amlogic USB Burning Tool to unbrick your device.  If you have or can find an original android firmware on the internet and you can generally (but not always) recover a bricked box using the Amlogic tool and the original firmware file.
 
 
Mapping from CPU to uboot and dtb:
 
u-boot-s905
s905 - gxbb
 
u-boot-s905x2-s912
S905X - gxl
S905W - gxl
S905D - gxl
S905L - gxl
S805X - gxl
S912 - gxm
A311D - gxm
 
u-boot-s905x2-s922
S905X2 - g12a
S922 - g12b
 
u-boot-s905x3
S905X3 - sm1
 
Not supported or not tested
S805 -
S905W2 -
S905X4 -
S805X2 - s4
A113D - axg
A113X - axg
 
 
 
Note: Followup posts in this thread should be limited to comments to improve or better understand these instructions.  Other issues should be posted as new questions in the Amlogic CPU Boxes sub-forum.

Change title to reflect the real question and moved to the appropriate forum

multiboot means different things in different contexts.  But in this context it is the process that is used for amlogic based tv boxes to get the native Android uboot on the emmc to boot armbian from SD card.  The process is to press the reset button with the SD card inserted which causes the native uboot to look for a certain file on the SD card which is then read and adjusts the uboot environment so that future boots will first boot from the SD card.

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

@Wizzard  The boot environment is stored on emmc.  So when you boot (enable multiboot via holding the reset button) that is setting certain variables in the u-boot environment and persisting them there (which is on emmc).  That is why you only need to press the reset button the first time you boot Armbian or any other distribution.  But the way that the distributions setup the boot environment are different (and usually not compatible) - even the Armbian legacy stuff from balbes150 changed how it was done (in incompatible ways) a number of times over the years.
 
So without knowing what has been changed in the u-boot environment that is stored on emmc, it is impossible to really support people.  So there is a check in the Armbian code that looks for certain changes that indicate something else has run and then fails the boot.
 
 

I was thinking of asking the same question.
 
Personally my feeling is if you are planning on helping Armbian by working to incorporate your efforts back into Armbian then I strongly encourage your efforts.  But I would recommend working with the Armbian developers on how you plan to do this, as it can be frustrating for you if you put in a lot of work into something, only to find disagreement from the Armbian community about how you are implementing something that might prevent it from being accepted.
 
If your intention isn't to incorporate your work back into Armbian, then you are creating just another fork (like the many that already exist), which you are entitled to do since this is open source.  But in that case I would request that you not use the limited Armbian resources to do that (i.e. our developers and infrastructure like these forums).  These forums are for Armbian developers and users, not for use by forks of Armbian that just attempt to take from Armbian without contributing back.

I was thinking of asking the same question.
 
Personally my feeling is if you are planning on helping Armbian by working to incorporate your efforts back into Armbian then I strongly encourage your efforts.  But I would recommend working with the Armbian developers on how you plan to do this, as it can be frustrating for you if you put in a lot of work into something, only to find disagreement from the Armbian community about how you are implementing something that might prevent it from being accepted.
 
If your intention isn't to incorporate your work back into Armbian, then you are creating just another fork (like the many that already exist), which you are entitled to do since this is open source.  But in that case I would request that you not use the limited Armbian resources to do that (i.e. our developers and infrastructure like these forums).  These forums are for Armbian developers and users, not for use by forks of Armbian that just attempt to take from Armbian without contributing back.

@Pita Bread Instead of using nearly two year old images, it probably would be best to start with the most recent images: https://www.armbian.com/amlogic-s9xx-tv-box

Yes, that added cost goes to paying people to provide the software support that users want and need.  Instead people demand software support from other people for free and get upset with Armbian and others when things don't work the way they want them too.  Nothing comes for free.

Yes, that added cost goes to paying people to provide the software support that users want and need.  Instead people demand software support from other people for free and get upset with Armbian and others when things don't work the way they want them too.  Nothing comes for free.

Note that this thread is archived.  Current information can be found at:
https://forum.armbian.com/topic/33676-installation-instructions-for-tv-boxes-with-amlogic-cpus
 

Ubuntu only started supporting jammy to noble upgrades with the .1 release that come out not that long ago.  So the upgrade to noble has only been available for a short time.
But in general, Armbian doesn't test distribution upgrades.  So Armbian will never recommend you do such an upgrade as it isn't supported.
However, if you know what you are doing you should be able to upgrade from jammy to noble.  I've done a couple of my own boxes and they have generally gone smoothly.

In the meantime I integrated the driver into armbian for rockchip64 targets: https://github.com/armbian/build/pull/7338 , so it will be a bit easier to test it out-of-the box and it would also be easier for amlogic people to copy-paste the driver patch and integrate the device trees as well.
 
My tests on hk1 rk3318 tv box (board silkscreen YX_RK3318) worked like a charm and the display is now pleasantly showing up-to-date date and time
 

The minimal builds are really minimal.  They don't include armbian config by default.  You need to apt install armbian-config if you want it.

So yes the emmc isn't detected (there is no mmcblk1).  Are you sure you have emmc on the box?  (I have for example some TX3 boxes that have old style nand instead of emmc and mainline linux doesn't support nand.  TV Box manufacturers will cut costs in anyway possible and nand is cheaper than emmc)  You would need open the box and inspect what physical chips are installed.
 
Since I don't have your box, there is little I can do to debug this.  Have you looked at the full log of the boot process to look for any indication of issues reported during the boot?  (You would need to find the debug serial console pins on the mother board and hook up a usb serial reader to capture the boot messages)  (some of this information goes to HDMI, but some gets output before HDMI is initialized).
 

@Ian Coelho How about some basic information first.  What build are you running?  What dtb are you using?  What dtbs have you tried?  How are you attempting to install to emmc?

The default is 'root' and '1234'