SteeMan

@jock - i think amlogic (the company) still is not very good regarding open source, but at least linux mainline is quite useable on their chips
 
the emmc clk pin trick works for amlogic too (if one finds it ) and wiping the emmc results in a boot from sd card ... the main problem is that the legacy u-boot reads its dtb from a later partition on the emmc and fails if it cannot find it - this is a problem if one for instance fdisk's and mkfs the emmc: the u-boot itself can still be intact, but it is bricked as it can no longer find its dtb (this is why the balbes150 amlogic images always kept 700mb and later more of the emmc in place when installing onto emmc to avoid overwriting this sensitive information) ... putting a mainline u-boot on amlogic boxes is possible but due to the complex boot structure and the required fitting blobs way more complicated than on rockchip and allwinner ... in summary: if amlogic then best is a properly supported sbc (odroid etc.) - unsupported stuff like tv boxes can result in quite a bit of extra work and unwanted surprises with those socs

Enabling multiboot is something that only should need to be done once, assuming it is done correctly.  It is persisted in the uboot environment stored on emmc.
Having said that, I have experienced cases where for some reason on some boxes the uboot environment gets reset to the default and multiboot does need to get re-enabled, but that is a rare occurrence, nothing I have ever seen happening on every boot.

Your assumption is incorrect.  The 'multiboot' changes the uboot environment stored on the emmc, even if you are trying to run something on sd.  The is the whole point of 'enabling multiboot' without the changes to the base uboot environment the board doesn't know how to boot from the sd card.  Those changes to the base uboot environment are different across different distributions and therefore the requirement to restore back to a known base with the original android firmware.

When designing a good sbc for general compute/server tasks I think you need a set of features that enable both a 'desktop' as well as 'server rack' deployment.  The reason for this is the evaluation process someone will likely undertake in order to buy into the boards features. No one is going to buy 32 boards for a 'server rack' deployment as the first purchase.  Instead they are likely to purchase one or a few to evaluate first.  That evaluation is not going to happen in a rack mount, but instead will happen on a desktop.  Once someone is comfortable that the base board works for their basic needs (i.e. the software and general hardware works), then they will explore the 'server rack' deployment options as they plan to scale a use of the board.
In my opinion therefore you need to make sure you have the features necessary to have a good evaluation experience on the desktop for the board ultimately to be successfully purchased in larger quantities for server work.  One example of this is an hdmi port.  While an hdmi port is completely useless in a server deployment, it can be quite useful during board evaluation on a desktop.  Another example is cooling as mentioned in the above posts.  I think you need to have good thermal design for both deployment scenarios (both as a desktop board and in a server rack mount), which might require different heat dissipation strategies for the different environments. Finally POE while likely unnecessary for a desktop evaluation is critical for a server deployment.
 
My ideal feature list would be:
1gbit POE ethernet port
4GB ram
32GB emmc (or more optional)
good external storage options (m.2 or other)
hdmi port
2 or more usb ports (at least one being usb3)
power port for non POE usage
optional case for desktop use with good thermals
optional rack mount with good thermals
 
The two things I think it shouldn't have:
- no wifi/bluetooth
The reason I say these are not desired is that good wireless (good antenna's, good software support) is difficult to design into a board, it isn't needed in the server rack case and can be accomplished better with a usb addon for the desktop case without incurring the added cost to the base board.
- no SD card
The reason I wouldn't include an sd card slot is if emmc is standard, that will be the preferred deployment storage media.  You only need another option to install/update the internal emmc and usb should be sufficient for that.  The sd support then just becomes an added cost with no real long term need.  It does require that booting from usb be well supported by the firmware.
 
Such a board would span a lot of use cases from general purpose single desktop use case to hundreds of boards deployed in dense rack configurations.
 
My personal experience is that I try things out first by evaluating one of something, then scale up to a few, and ultimately more as each step of the evaluation process shows the product is capable of the next deployment step.
 
Finally I'll mention price.  In my opinion you likely need the above described board at a price point no more than a RaspPi.  Given the large ecosystem and mind share built around that platform, and it is already capable of doing the above (although not well in many respects), you can't have something like this be at a 'high end' premium price point and expect it to be successful.  Price will to an extent drive the evaluation process.  If the price is considered too high, then people won't even start the evaluating, they will just stick with what the everyone else uses.
 

When designing a good sbc for general compute/server tasks I think you need a set of features that enable both a 'desktop' as well as 'server rack' deployment.  The reason for this is the evaluation process someone will likely undertake in order to buy into the boards features. No one is going to buy 32 boards for a 'server rack' deployment as the first purchase.  Instead they are likely to purchase one or a few to evaluate first.  That evaluation is not going to happen in a rack mount, but instead will happen on a desktop.  Once someone is comfortable that the base board works for their basic needs (i.e. the software and general hardware works), then they will explore the 'server rack' deployment options as they plan to scale a use of the board.
In my opinion therefore you need to make sure you have the features necessary to have a good evaluation experience on the desktop for the board ultimately to be successfully purchased in larger quantities for server work.  One example of this is an hdmi port.  While an hdmi port is completely useless in a server deployment, it can be quite useful during board evaluation on a desktop.  Another example is cooling as mentioned in the above posts.  I think you need to have good thermal design for both deployment scenarios (both as a desktop board and in a server rack mount), which might require different heat dissipation strategies for the different environments. Finally POE while likely unnecessary for a desktop evaluation is critical for a server deployment.
 
My ideal feature list would be:
1gbit POE ethernet port
4GB ram
32GB emmc (or more optional)
good external storage options (m.2 or other)
hdmi port
2 or more usb ports (at least one being usb3)
power port for non POE usage
optional case for desktop use with good thermals
optional rack mount with good thermals
 
The two things I think it shouldn't have:
- no wifi/bluetooth
The reason I say these are not desired is that good wireless (good antenna's, good software support) is difficult to design into a board, it isn't needed in the server rack case and can be accomplished better with a usb addon for the desktop case without incurring the added cost to the base board.
- no SD card
The reason I wouldn't include an sd card slot is if emmc is standard, that will be the preferred deployment storage media.  You only need another option to install/update the internal emmc and usb should be sufficient for that.  The sd support then just becomes an added cost with no real long term need.  It does require that booting from usb be well supported by the firmware.
 
Such a board would span a lot of use cases from general purpose single desktop use case to hundreds of boards deployed in dense rack configurations.
 
My personal experience is that I try things out first by evaluating one of something, then scale up to a few, and ultimately more as each step of the evaluation process shows the product is capable of the next deployment step.
 
Finally I'll mention price.  In my opinion you likely need the above described board at a price point no more than a RaspPi.  Given the large ecosystem and mind share built around that platform, and it is already capable of doing the above (although not well in many respects), you can't have something like this be at a 'high end' premium price point and expect it to be successful.  Price will to an extent drive the evaluation process.  If the price is considered too high, then people won't even start the evaluating, they will just stick with what the everyone else uses.
 

This thread is for the allwinner H6 cpu.  Your box as you mention has the H616 cpu.  Different CPU requires different builds.  There is no armbian working build for h616 cpu as of now.  Some work is happening on it, but it is likely a year out from being supported.

I want a stripped down board that has real 802.3af POE

Please first read:
https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first
 
Then read the following thread which should be relevant for your needs:
https://forum.armbian.com/topic/16859-allwinner-h6/
 

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

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

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

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

No, there is no current Armbian support for the H616 CPU variant.  Work is being done, but the general guidance is that support for this may be a year or so in the future.

I believe the brand name of this box is: MXQ 4k which is a rk322x based box.  Moving the post to the rockchip tv box forum

Use the "toothpick" method instead of trying the update app from android. 

Given the following comment posted in response to the new invalid message discussed above:
 
"Hi Werner, I didn't realise I'd posted this as a bug I'll post it elsewhere"
 
I took another look at the language in the big red warning message that is displayed for people posting new topics in the bug tracking forums.  While it would seem obvious to those of us on the inside what we are trying to communicate, to the novice user I think there is room to make it more clear.  To that end I have the following suggested wording changes:
 
Current text:
 
Wait!
To avoid common mistakes when opening issues use this form to make sure you have collected all necessary information and create your issue report at the correct place:
>> https://armbian.com/bugs <<
Issue reports that are not following these guidelines will be removed without further notice!
 
Suggested text:
 
Important Please Read Before Posting a New Topic (Bug Report)!
 
You are about to post a new topic in the Armbian Bug Tracker.  Armbian uses the sub-forums under "Bug tracker - supported boards and images only" as it's public facing bug reporting system. If you really intend to report a bug please fill out the following form to supply the necessary information for a valid bug report:
 
>> https://armbian.com/bugs <<
 
With limited resources the Armbian project is only able to spend time investigating bugs where all the requested information has been provided and for only the boards/images/software that are supported.  Your bug report will be considered invalid and receive no attention if you do not supply the requested information.
 
If you only have a question or are looking for help on something in general related to Armbian, you should be submitting your question in one of the "Community forums", such as "Common issues / peer to peer technical support" or "General chit chat", not in this bug reporting forum.

Given the following comment posted in response to the new invalid message discussed above:
 
"Hi Werner, I didn't realise I'd posted this as a bug I'll post it elsewhere"
 
I took another look at the language in the big red warning message that is displayed for people posting new topics in the bug tracking forums.  While it would seem obvious to those of us on the inside what we are trying to communicate, to the novice user I think there is room to make it more clear.  To that end I have the following suggested wording changes:
 
Current text:
 
Wait!
To avoid common mistakes when opening issues use this form to make sure you have collected all necessary information and create your issue report at the correct place:
>> https://armbian.com/bugs <<
Issue reports that are not following these guidelines will be removed without further notice!
 
Suggested text:
 
Important Please Read Before Posting a New Topic (Bug Report)!
 
You are about to post a new topic in the Armbian Bug Tracker.  Armbian uses the sub-forums under "Bug tracker - supported boards and images only" as it's public facing bug reporting system. If you really intend to report a bug please fill out the following form to supply the necessary information for a valid bug report:
 
>> https://armbian.com/bugs <<
 
With limited resources the Armbian project is only able to spend time investigating bugs where all the requested information has been provided and for only the boards/images/software that are supported.  Your bug report will be considered invalid and receive no attention if you do not supply the requested information.
 
If you only have a question or are looking for help on something in general related to Armbian, you should be submitting your question in one of the "Community forums", such as "Common issues / peer to peer technical support" or "General chit chat", not in this bug reporting forum.

I don't see a problem with using the invalid label as it is invalid according to the directions the user has read (or not read).  What I think would improve this is giving the user more direction on what to do next.  I think some working changes in the post that closes the thread as invalid would be all that is necessary.  So instead of:
 
 
Your issue report is invalid for one or multiple reasons (non-exhaustive enumeration):
 
it has been stated at the wrong place
it lacks fundamental requested data
it could have been easily solved by a quick search and/or reading documentation
unsupported userspace/image/SBC
 
Since you refused to use the bug reporting form carefully and follow the information there as you have been asked for we have no intention to further investigate.
Please add missing information if applicable.
 
https://www.armbian.com/bugs
 
 
Something like:
 
Your issue report is not a valid bug report per the Armbian bug reporting instructions (https://www.armbian.com/bugs).  With limited resources the Armbian project is only able to spend time on issues where all the requested information has been provided and for only the boards/images/software that are supported.  Your report is invalid for one or more of the following reasons (non-exhaustive list):
 
- it is for an unsupported board or image
- it is for software that isn't supported (such as userspace modules installed on top of the core operating system)
- it has been logged in the wrong forum (for example requests for help that are not actual bug reports)
- it lacks requested data (armbianmonitor output)
- it could have been easily solved by a quick search and/or reading documentation
 
Please review what you have submitted and the bug logging instructions (https://www.armbian.com/bugs) and either add the required information or open a new topic in the correct forum (such as "Common issues / peer to peer technical support" or "General chit chat")
 
 
I think this softens the tone and tries to help the user do the right thing.  Which they likely still won't 
 
 
 

One of the interesting features of extlinux.conf is the ability to present a boot menu.  I have played around with it a bit to have different kernel versions installed and switch between them at boot time.  With a boot menu and hdmi support in u-boot, it brings some nice capabilities.

Have you read the thread dedicated to TV boxes with your CPU: https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes
 

Beware that there are different hardware versions of this same box. I myself have two X96 Max boxes, with two different hardware versions, both bought just days apart from each other. It has been a few weeks since I had the chance to play with them, but from what I recall, one of them worked OOTB with Armbian 20.10 5.9.0 and the expected dtb (x96max). The other one is instead more similar to the X96 Max+. It came with an 8822CS wifi chip (same as the Max+) instead of the AP6356SA that came on the first one. The "original" version of the X96 Max does work ethernet @ Gbit speed and WiFi OOTB with the 201014 image. The second one I do not recall now if I ended up managing to use either of the (onboard) network interfaces or if I simply plugged a USB wifi dongle at the time. I had but a couple hours at most with them. I plan to play again with them soon, I will let you know more details once I have the chance to check. Bottom line, first of all check what hardware you got inside your box!

@Mohammad Shami Please read the two posts in the TV Box Club's FAQ forum

@MX10.AC2N I think you are approaching your issue from the wrong perspective.  As balbes already mentioned he "doesn't use this software and has no idea what it requires'.  So essentially asking the same question in a different way isn't likely to get a different answer.
 
You need to understand that the armbian project is about getting the mainline linux (debian and ubuntu distributions) to run on arm SBCs (and luckily that often works on TV boes as well).  Information and support of the thousands of software programs that can then run on debian or ubuntu isn't something that armbian is about.
 
NextCloud is a software product and you want to run that program on your armbian based TV box, which is great, but you should be looking for support from the NextCloud community for support of their product.
 
You mention in your posts NextCloudPI.  I'm not sure why you are going down that particular path.  You should be able to just install NextCloud following their instructions for your chosen distribution (debian or ubuntu).  I have been running nextcloud on one of my amlogic s905w based TX3 mini boxes for over a year using the snap version for my ubuntu bionic install.  It was easy to install, it automatically updates itself and I haven't had to think about it in a long time.  That is exactly what you want from a server based software program.  Now if you ask me what i did over a year ago to get it installed, I will have no recollection, but I just followed the readily available instructions available from nextcloud to get it done - didn't need to post anything to armbian forums to install a generic software product.

I moved the above to a separate thread as the content is distinct from the thread it was originally posted in.

I am pleased to report the 20210303 images (I tested Focal) work great (copying to EMMC using standard Armbian method) on the T95 Mini box.  FYI, this is my favorite TV box as it is small, has a nice enclosure and good thermal properties (CPU usually around 50-55 degrees).  And it is available < $20 (USD) on Alibaba in small quantities.