TRS-80

It appears you are correct!  I don't have this board and never noticed that before.
 
 
I will move it to the appropriate forum now.

Generally speaking, there are several boards meeting your requirements, as "server" use-cases (as opposed to "desktop") have been much better supported for a much longer time now.  I used Cubietruck for such tasks for very long time (and still do) however there are better boards available nowadays for actually even less money (read on).
 
Now to specifics, I used to think SATA was necessary, too, until I read this glowing review of particular USB to SATA adapter by tkaiser (from 2017!).  Surprisingly, this device is still available here.  I have several of them and they have worked well for me.
 
If you are willing to consider such adapter (instead of strictly sticking with SATA requirement, which as you noticed is more rare), this of course open up the possibilities a lot.  When I needed to buy another little "server" board a year or two ago, I chose ODROID-XU4 at that time which are (like Cubietruck) still 32-bit, however still quite powerful with a lot of CPU and USB3 and RAM, etc. and can be had for ~60 USD these days.  Other than the adapter caveat, this meet all your requirements and I think you might be happy with, I know I (and others) have been.  I think they went down in price because they are "only 32-bit" however this means (to me) just a good deal to be had (maybe?).    To make "apples to apples" comparison, you will need to add the price of PSU, eMMC, SATA adapter, etc. to that figure, though.
 
And that is where I personally am at, currently.
 
Now going forward, there are a lot more newer and more interesting boards, especially some of RK3399 (64-bit) based ones as Werner brought up.  One of these will probably be my next purchase at some point.  They will cost a little more (I think?) but as always, add costs of PSU, flash (eMMC or sdcard), etc. to get the full picture on any price comparison.  Some of RK3399 even support fancy stuff like NVMe, etc.
 
One final generality, I always recommend to stick to Armbian Supported Devices list as a starting point for any research.  But you probably know that already.    And remember, even some boards that look great "on paper" can have little gotchas, or be better for this use case or that, e.g., N2 have most raw power in CPU but is limited by I/O.
 
I learned that on some NicoD (YouTube) video, he has made some good ones, maybe you want to check them out.  He is focused more on "desktop" usage, but has a lot more experience with a lot more boards than I do, especially some of these newer ones and so I find his videos still very informative.
 
Let us know your thoughts more and how your research is coming along, if the right person see your post maybe they save you from one particular little problem or another.

I wanted to share an article I came across, I thought was pretty good.  Keep in mind I am starting from zero with Docker recently, if you are already familiar, this article might be too basic for you.  The article walks you through several of basic Docker tasks (create, run, inspect, ssh into, etc.) on command line:
 
Getting started with Docker for the Inquisitive Mind
 
They have other related content on their site as well which I have only skimmed so far, but it looks pretty good.  I always appreciate websites with clean looking CSS that work well (including mouseover effects) without requiring JavaScript to be enabled (which I block by default). 
 
What's everyone else been up to?  Come on, don't be shy now. 

I have been having some long running, on and off discussion with @lanefu in IRC (and elsewhere), because I know this is his area of expertise.  However he is busy, and I can appreciate he might not want to spend his free time talking about stuff he gets paid to do M-F. 
 
Then I also realized, certainly I am not the only one interested in Armbian in order to be doing such things.  So I thought I would make a thread about this, instead, to open the discussion to a larger group people here in the broader community.
 
I have my own thoughts, concerns, things I want to do, and have already done, but I thought I would make a more general thread where like minded people can discuss their experiences, what has worked (or not), what services you might be running (or would like to), etc.
 
I guess I will begin by saying I have been running some services for family and friends, first on a Cubietruck since maybe 2017 (or earlier?) and then later on some ODROID-XU4 in addition.  I run XMPP server (Prosody) which has been very hassle free "just works" as well as some experiments into Home Automation and other things which have had some, well let's just say mixed results. 
 
Currently my interest is in containers and like technologies, but I am very new to it.  I been reading a lot, but there is so much to know and I can't help but feel I am a bit late to the game.  That's by design though, as I don't like being (too) early of a technology adopter, generally speaking.  Well, certainly not with such "hyped" technologies like containers, anyway.
 
In fact I thought it was a bunch of baloney and hype for a long time, but even cranky old cynic like me now sees some advantages of abstracting things, changing servers/services from "pets" to "cattle" if you will, for reproducibility, redundancy, and other reasons.
 
Anyway, I am prone to walls of text of idiotic ramblings, so I will stop here and give some others a chance.    Hope everyone is enjoying their holiday weekend so far. 

OK, so while documenting the Armbian patch process I needed something actual to patch. I added gpio-line-names to the device tree, so now all lines are defined. Once I finish the documentation I'll PR this patch. No more guessing what physical pin is! At some point it might make sense to put in jumper and physical pin #.
 
 
 

(emphasis mine)
 
That's the spirit!   
 
IMO, everyone who play with SBC should own at least one.  In fact, it's on my list to add that to the docs, right in "Getting Started" section...

This is an adaptation of something @SteeMan wrote in this post, but we need to refer to it often enough that I thought I would make it into a sticky.
 
Amlogic (S9xx) Android based TV Boxes

1. They are not supported.
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 build that will maybe work on your box.
4. There is a very small number of people on this forum/club that are able to provide any guidance.
5. Most likely no one on this forum/club has ever seen your specific box.
6. 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.
7. You really shouldn't expect things like Wi-Fi, bluetooth, remote control, etc. to work.
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 certainly not video/multimedia.
 
Other RockChip (rk3399, rk3328, rk3288) and Allwinner (H5, H6) based TV Boxes
 
9. These will continue to be supported within the limits that are possible for the equipment the devs possess.
10. They are (in fact, have always been) CSC which means Community Support only!  In other words, not officially supported by the Armbian project!
 
So, why even have these forums?
 
As a place for people to try and get together and help one another.  At least it is something.
 
Also, there used to be a lot more (better supported) activity here while balbes150 was still releasing his fork of Armbian.
 
What other options do I have?
 
I (@TRS-80) recommend cutting your losses and starting over, and this time around using the list of Armbian Supported Devices as a starting point for researching purchasing some other device.  Taking this approach will result in a much easier time, less hassle, better support, and usually for a much longer period of time (assuming things for your device get mainlined into Linux kernel).
 
Even using that list as a starting point, do your homework.  As any particular device can have some little quirks / gotcha(s).  There are a lot of resources available on the (wider Armbian) forums already, please use them!
 
@SteeMan however takes a different view.  He lay out his arguments in favor of trying anyway (see below) in spite of all the above.
 
If you choose to go that route, at least we can say we warned you now. 
 
Why is situation like this?
 
Source of following quote was Armbian official Twitter, on 2020-12-02 11:23 EST:
 
 
SteeMan also touch on this in his excellent post, below.
 
Now hopefully you at least understand why most people may not wish to spend their own valuable free time to help someone who chose an unsupported box, mostly because it was cheap (and possibly without even doing much research beforehand).  SteeMan (and a few other guys in here like jock and some others) being the rare exceptions who relish a challenge.
 
Good luck!

but those are fixed ip cores in the hardware and not loaded later - if you want to get rid of those i think you have no chance to get a useable system going at all ...

Hi,  I was just in the armbian matrix channel asking about FLOSS SBCs, SBCs which can be booted / operated without blobs or with as few blobs as possible.

I am not one of those purist Stallmanite zealots who refuse to touch anything which i deem imperfect in the freedom department. Instead I am just trying to be practical and figure out whats the best options for SBCs which respect users. SBCs whose security/integrity is verifiable and doesn't hinge on appeals to authority, like "just trust our secret sauce, it will be fine".

I want to know about any projects from the past, things that are in progress, and hear experiences from folks who are interested in open source firmware, bootloaders, etc.  I got the general idea from talking in the matrix channel that there are actually more FLOSS-friendly SBCs than a cursory google search might indicate, and I would like to discuss and put together a list.  Goal would be that this can perhaps be published somewhere, I'm not sure where would be the appropriate place on the Armbian documentation or web site, but I can also publish it myself and try to keep it up to date as this is something I'm keenly interested in.

So, without further adieu, I will start, these are the projects I know about which I'm interested in:

Bootloader software projects:
https://libreboot.org/
https://www.coreboot.org/

It's not an SBC, but there is this project to have an open source bootloader/firmware linux laptop based on this chrome book: Asus c201 with RK3288
https://github.com/SolidHal/PrawnOS

This old open source hardware board I believe can be run with open source firmware but its quite slow and less than 1 GB RAM
https://www.olimex.com/wiki/A10-OLinuXino-LIME

Someone from matrix said that the ROC-RK3399-PC (http://en.t-firefly.com/product/rocrk3399pc) can be run without blobs:
 

Please let me know about any other open source firmware/bootloader for SBC projects that you know about!!

Armbianmonitor: http://ix.io/2HqW I'm not sure if I should pursue this here or if I should open a ticket through Debian Bugs.
 
A recent update now causes mpd to segfault. mpd comes from the Debain armhf repository.
 
I'm not sure how to determine if this is a hardware issue with my board somehow or if there is an interaction with a new kernel or if it's because the package updated the binary or a library.  To make sure it wasn't something weird in my configuration I moved the conf file out of the way and re-ran mpd with the same result.
 
If it helps, I can post an strace output of the issue.
 
James

I have exactly the same need, except I am looking for two identical boards : it is my KISS (*) version of a cluster of application, storage and backup server with disk redundancy. One application and storage online server and an other offline backup/archive server with the same content + the archives. So I can switch the boards in case of failure or restore the content of last day in case of file loss.
 
I use two BPI M1 at present - one having lost its USB ports. One SSD for app and one bigger HDD for bkp. 
So ? SATA is "has been" and is over-performed my new standards but it fulfill my present requirements, and it is a cheap and conservative solution. TRS-80 is wright : the best is to use USB3 and a converter (you will experience a huge improvement comparing BPI), so you are not limited on the choice of the boards and will continue to use the disks for years. Just, some return of experience will be valuable for choosing one : for my desktop, I buyed a uASP able JMicron controller which is allegedly not compatible with a via controller and seems a bit power hungry. 
 
So any modern Rockchip 64 bits, reasonably priced fanless boards that do not consume to much power would do the trick for me. (2 boards and 2 "good" adapters). And with OS on disk, no need for eMMC. 
 
(*) KISS : Keep it simple stupid. Security is antinomic with complexity. And when you experience a hardware failure many years after having put in place the machine and forgotten everything about how it works, the last thing you need is complexity and deprecated, out-of-date, not retro-compatible or not replaceable software or hardware.

Or is it the other way around?

Because we decided to not waste more of our private time and our private money for dealing with hardware "you" purchase for a few bucks. And with "your" endless continuous questions for which you rarely give even a "thank you" for. Not entirely nothing to be fair - you still cover around 0.5% of our running costs with the donations.
 
 
Armbian has nobody that have time to work for you. How a board gets a support is usually determined this way:
but there is some grey zone in between. Some boards - where support is cheap in term of time - can skip this process.
 
 
We didn't hide or break anything intentionally.  What you are looking for, it was not developed at all.  Read this section before you get more ideas what we should or shouldn't do for you. Also look forum https://forum.armbian.com/forum/38-feature-requests/ where is a pile of wishes we have no resources even to read what's about.

I fully agree with @TRS-80 comments above directing most users towards officially supported SBC hardware options.  However, I do want to add my own personal thoughts on why I choose to continue to use these Android TV boxes with unsupported armbian running on them:
 
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 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 longer lasting 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.
 
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.
 
I feel that if someone wants to use *unsupported* armbian on TV boxes and has the correct expectations (set your expectations low) and is looking to learn and is up for a challenge these are fun things to work with.  And I look forward to working with you on these forums.

Well, I guess I would consider maintaining download links, documentation, etc. and other things you mention as a part of "support."
 
I think you are very lucky to have @SteeMan helping you.  Which I would also consider "support", by the way...  And also why I don't understand the slightly snide / passive aggressive comments like
 
 
directed toward people who are trying to help you.
 
As I said in my first post to you, I can empathize with your frustration, we have all been there.  Please, really stop and consider that for a moment.
 
Because speaking to other members of the community (especially those rare and valuable people like SteeMan who so selflessly contribute their time and efforts to help others) is not going to be tolerated.  Consider this an official warning from a Moderator.  So maybe take a break or whatever, go for a walk, or at minimum think about how you are talking to people, especially those who are trying to help you, before making your next reply.
 
Cheers.

Update : It was a mesa bug that produced the crashes. 
RK3399 is now back stable with latest updates. Even at 2Ghz and ondemand governor. 
But not all problems are fixed yet with mesa/panfrost. The errors in dmesg are still there. And some things that use panfrost will not work. 
Mesa has had a major update to version 20.2.4. So if you need panfrost, best to use mesa 20.2.3. https://docs.mesa3d.org/relnotes/20.2.4.html
You can also download the old version of Armbian Reforged with mesa 20.2.3. But be sure not to upgrade for the moment. 
 

Like this?
until apt update; do sleep 90; done  

@FHam 
First I want to restate some of the basics around armbian on android tv boxes.  1) They are not supported.  2) A single developer (balbes150) has worked years on getting things to the state they are.  3) As of October 14th balbes150 removed support for amlog cpus, so that is the last build that will maybe work on your box, 4) There is a very small number of people on this forum/club that are able to provide any guidance, 5) Most likely no one on this forum/club has ever seen your specific box, 6) 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.  7) Really don't expect things like wifi, bluetooth, remote control etc to work.  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 certainly not video/multimedia.
 
There is a lot of information in the two threads you have opened on your installation problems.  I think at this point it would make sense to start from the beginning and step through the basics to try to help you.  There were a couple of very important questions asked of you in the old closed thread that you didn't answer.  I am going to make some recommendations in an effort to try to help.
1) Use the latest/last build that supports amlogic cpus: https://yadi.sk/d/_rQgn_FosYuW0g/20.10/20201014
2) Follow the instructions (I agree that the instructions are often not clear) from the first post of this thread: 
I recently wrote a post that attempted to help someone better understand the instructions for an amlogic cpu as he was having difficulty understanding the instructions from balbes150.  This may help you:
 
 
 
3) Pay particular attention to the first sentence in red.  If you have ever tried to install other linux builds on this box, stop.  You will first need to restore the box with an original android firmware before continuing.  This is true even if the box is still running android.  The key here is if you have ever 'attempted' to install something else.  The installation process for some other firmwares will modify the booting environment in ways that cause the armbian install to no longer work.  The armbiantv installation is dependent on an unmodified default android environment.  I have more than once solved problems I have had by reverting a box to a clean fresh state by reinstalling the android firmware.  Note, when I say reinstall the android firmware, that doesn't mean using the android functionality to reset the box, it means going out and finding the correct manufactures firmware file and using the low level amlogic tools to install that on your box.  This is one of the questions asked in the previous thread that you didn't answer, which is why I am spending so much time on it.  It is critical that the state of the box be known and clean otherwise we are all just wasting time.
 
4) In your previous thread you have a screen shot showing you trying to run aml_autoscript.zip from android recovery.  From my understanding if you find yourself in android recovery you are doing something wrong.  No part of the installation process uses android recovery.  I have always been successful with the 'toothpick' method and would recommend you stick with that.  
 
5)  The extlinux.conf file you posted in the previous thread had a number of errors in it.  Please post the extlinux.conf file you are currently trying to use.
 
You are working with a box that isn't common.  I have no experience with it.  But by correctly following the installation, you may yet be successful. 

@FHam,
 
I wish you best of luck in getting this working.  It is possible (maybe?), however can be difficult (as you are perhaps finding out).
 
If you cannot get it working, or get tired of messing around with unsupported devices, you could also consider starting over with one of Armbian officially supported devices, where you would not only have a much easier time, but also enjoy long term and (generally) much more stable support situation.
 
Just something to consider.  I really feel bad for you guys struggling with these TV Boxes in here.  But the wide variations and random hardware make them extremely difficult to support.  And without software support, the most impressive specs in the world "on paper" really don't mean anything.
 
By contrast, I am enjoying a couple well supported devices for a number of years now, they run flawless and for the most part "just work."  Just keep it in mind, the next time you go device shopping...

Well, I guess I would consider maintaining download links, documentation, etc. and other things you mention as a part of "support."
 
I think you are very lucky to have @SteeMan helping you.  Which I would also consider "support", by the way...  And also why I don't understand the slightly snide / passive aggressive comments like
 
 
directed toward people who are trying to help you.
 
As I said in my first post to you, I can empathize with your frustration, we have all been there.  Please, really stop and consider that for a moment.
 
Because speaking to other members of the community (especially those rare and valuable people like SteeMan who so selflessly contribute their time and efforts to help others) is not going to be tolerated.  Consider this an official warning from a Moderator.  So maybe take a break or whatever, go for a walk, or at minimum think about how you are talking to people, especially those who are trying to help you, before making your next reply.
 
Cheers.

I have been having some long running, on and off discussion with @lanefu in IRC (and elsewhere), because I know this is his area of expertise.  However he is busy, and I can appreciate he might not want to spend his free time talking about stuff he gets paid to do M-F. 
 
Then I also realized, certainly I am not the only one interested in Armbian in order to be doing such things.  So I thought I would make a thread about this, instead, to open the discussion to a larger group people here in the broader community.
 
I have my own thoughts, concerns, things I want to do, and have already done, but I thought I would make a more general thread where like minded people can discuss their experiences, what has worked (or not), what services you might be running (or would like to), etc.
 
I guess I will begin by saying I have been running some services for family and friends, first on a Cubietruck since maybe 2017 (or earlier?) and then later on some ODROID-XU4 in addition.  I run XMPP server (Prosody) which has been very hassle free "just works" as well as some experiments into Home Automation and other things which have had some, well let's just say mixed results. 
 
Currently my interest is in containers and like technologies, but I am very new to it.  I been reading a lot, but there is so much to know and I can't help but feel I am a bit late to the game.  That's by design though, as I don't like being (too) early of a technology adopter, generally speaking.  Well, certainly not with such "hyped" technologies like containers, anyway.
 
In fact I thought it was a bunch of baloney and hype for a long time, but even cranky old cynic like me now sees some advantages of abstracting things, changing servers/services from "pets" to "cattle" if you will, for reproducibility, redundancy, and other reasons.
 
Anyway, I am prone to walls of text of idiotic ramblings, so I will stop here and give some others a chance.    Hope everyone is enjoying their holiday weekend so far. 

I am posting because I can empathize with your frustration, so please take this in the way it is intended (a constructive hint, even if not directly related to the issue you are trying to solve).
 
So now perhaps you guys start to understand why TV Boxes are not officially supported.  Because getting them to work can be "an adventure" to say the least.
 
I wish you both the best of luck, sorry I don't know any more specifics which might be directly relevant.

In the meantime I received a quite interesting reply on my above linked thread from none other than tkaiser himself.  It's quite long and full of lots of good info, but the TL;DR is that I am re-thinking my position on btrfs now, most especially on ARM (while overall, and on x86 especially I maintain my position).  But maybe you guys know all of that already and that's why you use btrfs in the first place. 
 
However if I am going to shit up someone else's thread, especially with (apparently wrong) information, the very least I feel I should do is return and issue a retraction / update.
 
Cheers!

@scottf007,
 
Igor's comment was more directed at the others in the thread who are trying to solve this particular bugbear.  In other words, mostly development talk.
 
There are lots of clues and instructions littered throughout these forums that will tell you how to get this working.  However if you get too frustrated or can't figure it out, just wait a bit longer and eventually something will be released to make this "easier" for the average Joe.

I did the install of the latest armbian build and the device is now rock solid, no reboots after 18 hours - compared to between one and four hours to failure before the upgrade.
 
For the benefit of others who wish to repeat the process here are my install steps. I used a fairly powerful debian buster desktop to do the build but it still took some time, maybe half an hour including download time? I chose to only build the kernel elements by answering the prompts from the build script compile.sh
 
cd /usr/src/ git clone --depth 1 https://github.com/armbian/build mv build build-armbian cd build-armbian/ ./compile.sh docker cd /usr/src/build-armbian/output/debs scp *.deb root@192.168.0.1:~ ssh root@192.168.0.1 dpkg -i armbian-firmware-full_21.02.0-trunk_all.deb linux-dtb-current-rockchip64_21.02.0-trunk_arm64.deb linux-image-current-rockchip64_21.02.0-trunk_arm64.deb linux-u-boot-current-nanopi-r2s_21.02.0-trunk_arm64.deb systemctl reboot