Marketplaces and e-waste recycling centers are practically overflowing with the things: ARM-based streaming TV boxes that run some — usually very outdated and compromised — version of Android. While you can use them for their promised streaming purposes, they’re invariably poorly optimized and often lie about their true hardware specifications. Which leaves the most important question: can you install Linux on these SBCs and use them as a poor man’s Raspberry Pi alternative? The answer, according to [Oleksii’s Tech] on YouTube is ‘sorta’.
The commonly seen X96Q clone Android TV box that [Oleksii] bought for $10 is a good example. The clone advertises itself as based on a quad-core Cortex-A53 AllWinner H313 SoC, like the genuine X96Q, but actually has a Rockchip RK3229 inside with correspondingly far lower performance. After you have determined what the actual hardware inside the box is, you can get a copy of Armbian for that particular SoC. Here, the Rk322x-box minimal image was used, with the box booting straight off an SD card. Some Android TV boxes require much more complicated methods to even boot off external media, so this was a lucky break.
Continuing the hardware scam, it was advertised as having 2 GB of RAM and 16 GB of Flash, but it actually has just 1 GB of RAM and 8 GB of eMMC Flash. This was enough to get Armbian desktop up and running, but that’s about all you can do on the desktop. Desktop application performance was atrocious, mostly due to the CPU’s quad Cortex-A7 cores struggling to keep up.
As also suggested in the comments, the best use for these low-spec SBCs is probably to run light server applications on them, including Pi-Hole, Samba, an IRC bouncer, and so on. They’re pretty low-power, often have the requisite Ethernet built in, and it keeps another bit of potential e-waste from getting scrapped.
Has anyone tried to install FreeDOS or another very minimal open source OS on one of these?
Is it possible, with or without flashing the UEFI/BIOS?
Because of their price point (cheap or free), I’m thinking about using them in an elementary school, for simple coding and typing tutor.
FreeDOS still seems to be x86 centric, though some initiatives about porting to ARM seem to exist…
The basic functionality of DOS relies heavily on 16-bit instructions and interrupts of the x86 architecture. I think if you’re going to emulate that on ARM you might as well opt for Dosbox or QEMU
i’ll just point out here that cp/m-68k is written in c and it is possible, with a bit of work, to make it go through gcc.
There are bare metal X86 emulators for the raspberry pi, So porting one of those to that kind of box to run FreeDOS isn’t impossible…
+1
There’s als PC-MOS/386 v5 which is Open Source, too.
It’s a real multitasking/multi-user operating system.
It supports the 80386’s enhanced capabilities, but also runs on 8086.
Digital Research’s ancient DOS Plus is also an option.
It’s very small and based on an emulator itself.
“PC-MODE” converts DOS 2.11 calls to CP/M-86, basically.
Like an API or ABI wrapper, more or less.
In principle, it’s possible to build a custom ARM DOS that uses native ARM code,
but emulates the MS-DOS API (software interrupts such as int21) on an x86 emulation core.
That should be blazing fast.
Especially if the back-end for storage or network would be using native code.
Even multi-threading would be possible. Each core could have a specific task to do.
Merely a little bit of DOS-specific hardware would be needed to emulated, to please existing DOS applications.
Things like VGA, mouse, sound and network.
But that could be using high-level approach.
VGA has VGA BIOS and VBE extension, so merely mode 13h (320×200 256c) and mode 12h (640×480 16c), VBE 6Ah (800×600 16c) and VGA text-mode are really important in most cases.
And a basic register set of VGA and the VGA framebuffer have to provided. A synthethic/generic VGA device, basically, with many registers being dummies.
Or a rudimentary MCGA circuit with just VGA mode 12h added.
This should suffice 90% of the time, I guess. Games use tweaked VGA modes, though.
Network support is really easy to implement.
Either by emulating an NE2000 NIC or by emulating a simple DOS packet driver interface directly inside the DOS implementation.
Most DOS applications can use one of them.
Sound emulation could be Covox SpeechThing (DAC on 8-Bit parallel interface) or a Sound Blaster, for example.
The real Sound Blasters use an 8051 microcontroller as a “DSP”.
The commands could be simulated in software or emulated (5051 code).
DMA support must be provided, maybe. Though there also was normal programmed i/o.
Not sure how many application supported both modes, though.
But I’m just thinking out loud here.
Implementing a whole DOS environment for ARM would be simpler and better performing than making an unmodified DOS run through help of emulation layers.
In principle, ideas of MS-DOS Player and DOSBox could be used combined to develop a blazing fast DOS environment.
Like WINE with an built-in x86 core, but for DOS.
If it has idle detection, it won’t keep hogging the CPUs all time.
In principle there would be very “emulation” happening.
DOS applications would just call int21h services which are as efficiently being handled by the “fake” DOS,
which then call native ARM code.
Without another operating system helping it.
If you want DOS, you should probably just install an emulator on the stock Android / or replace the firmware with Armbian then install an emulator. As others have noted, most DOS applications are not designed to be device-independent.
..or maybe just run Python on Armbian. I think that should be enough for teaching some basic coding skills.
Regarding UEFI/BIOS, some modern ARM boards DO support UEFI, but those are not common. U-boot is a much more common open-source bootloader out there (although this is not always given, either). With U-boot, you usually have to supply a device-specific device tree in your boot image. I heard that modern U-boot builds do partially implement UEFI, but I don’t know if it is complete enough that you can just skip this and run a generic Linux image (instead of relying on dtbs).
You can easily buy real 386 PC if you want to do vintage gaming. I ordered mine from e-waste dealer in Namibia and it arrived in just 2 weeks.
Hi! Simple line based text-mode applications often are, those that would work on a serial terminal via CTTY command.
Things like compilers, linkers, info programs or simple ASCII games.
Examples: Clipper, Mix C, MS Macro Assembler, Edline, Turbo Pascal 3, Zork, Ladder, Castle Adventure etc.
Such DOS applications work on IBM PC, DEC Rainbow, Sanyo MBC 550, Sharp MZ 6556, NEC PC-98 and FM Towns etc.
They’re basically compatible with all “MS-DOS compatibles” (computers running DOS) because they’re using DOS for basic i/o.
Applications using text-mode video buffer of MDA or CGA/EGA/VGA don’t work, of course.
Strictly speaking, there also was GSX, an hardware-independent graphics API.
But it didn’t catch on DOS (it sorta did on CP/M and CP/M-86).
GEM and MS Windows took that role in the end.
They were ported to all sorts of non-IBM computers.
Still, MS-DOS itself will boot without any graphics hardware or keyboard. It can be entirely operated via CTTY.
On a PC without display/keyboard, CTTY command must be in autoexec.bat, so the console can be re-directed to a terminal.
In the past, this was done in order to have over 900 KB of conventional memory,
to run compiler/linker that need large amounts of RAM for a project.
sure, you’d think so. i had to give up on turbo c 2.0 on my dec rainbow because the command line version of the compiler used ibm pc bios calls to determine whether you had pressed ^C while it was grinding away on your code.
I’m speaking from experience with Android tablets, but hardware-wise these are pretty similar. First, bear in mind that these are ARM devices, so no standalone DOS, you would need a host OS and and x86 emulator. Also, these devices don’t have any standarized pre-OS environment, so this excludes anything like UEFI or BIOS. The bootloader & kernel need to be configured for a specific board, which involves “a little” or “a lot” of work depending on how much public information is available.
Unless you are willing to put in quite a bit of work, I would assume that other options would be a better match for your case. For example second-hand “thin terminals” as used in various corporate environments – these are low-end PCs that can run stock software. They are slightly more expensive though (a quick search on a Polish auction site shows these for an equivalent of 16eur).
This was meant as a reply to Andrew.
“a lot” of work
agree.
Getting DOS itself to boot would be fairly simple,
as it merely needs BIOS as a runtime and the basic 8086 instructions set.(With 80286 instructions set being highly recommended, 386+ instructions set would be ideal for DPMI/DOS4GW applications.)
As an analogy, the “old world” Power Macintoshs with the Mac’s Toolbox in ROM can serve here.:
It had an 68k emulator of ~40 KB size, I think, which was used by the classic Macintosh operating system in the PPC era.
(Later, if I understand correctly, the ROM content of “new world” models
went into a hard disk file to be loaded in RAM at runtime
and MacOS 9? itself got a dynamic 68k re-compiler.
The pyhsical ROM itself remained in use, but as a simple bootloader.)
https://apple.fandom.com/wiki/Mac_68k_emulator
https://en.wikipedia.org/wiki/Mac_68k_emulator
https://developer.apple.com/library/archive/documentation/mac/PPCSoftware/PPCSoftware-13.html
Something similar could be done for DOS, perhaps.
An x86 emulator with BIOS/VGA BIOS+VESA BIOS, as an UEFI payload. Maybe IBM 8514/A, too. It was being supported by a few graphics cards.
That would be good enough for booting MS-DOS 5 or 6.x, at very least.
Things like audio support would require Sound Blaster emulation,
since it was a de-facto standard (SB32/AWE32 would be ideal).
Though Covox SpeechThing/SoundMaster, PAS16, GUS, Windows Sound System (WSS) also had some relevance.
Mouse support would require MS Mouse emulation, maybe.
Or Genius/Mouse Systems emulation etc.
First of all onderfull project :) anything with low consumption that can be saved from the landfill and made useful is a great thing :D
Second I’m surprised that it performs so bad with delays noticeable just browsing the desktop menus as it’s supposed to drive graphical interface and HD streamsd in it’s normal android TV-Box life. I’d bet that there is some missing or mis-configured driver(s) in the graphical pipeline (disabled DRM support ?) thus unloading some graphical processing on the general purpose cores ending-up overloading the CPU.
Agreed; Hardware that is built to play streaming video likely has the horsepower to handle a 2d GUI just fine. Slowness is probably due to slow disk IO and missing hardware acceleration drivers.
Great maker, how far software efficiency has fallen. Back in my day, this would be a killer hardware platform — even for a “real” desktop box.
I’m with ya, but you have to acknowledge that it would take 10x longer to code something that would run efficiently under such constraints. All code is bloated as heck now because it’s all done using libraries and such that allow the program to be written much faster at the cost of size and system requirements. I do miss the bare metal assembly days, though – you had full control over the machine & knew EXACTLY what it was doing at all times.
Yup. Let’s just replace Megabyte by Gigabyte to get a feel for it. Or vice versa.
Some people call this “progress”. However that’s meant to be understood.. 🥲
I use a cheap android tv box as my Home Assistant server and it has been working great for the last 2 years, actually really happy with it :)
Seems the “fake” specs is the bigger problem in that space than E-waste.
“While you can use them for their promised streaming purposes, they’re invariably poorly optimized and often lie about their true hardware specifications.” What is this sentence trying to say? They don’t need to be optimized or honest, they need to play Netflix and Youtube or whatever. ??? I understand there may be problems using these for the intended purpose, but i would rather not write anything than just hand wave at it. Seems like there’s a story here about marketplace fraud that is being assumed instead of told? FWIW i’ve had mostly good luck at getting what’s advertised, in part because i eagerly buy things advertised to be pathetic. :)
Anyways i agree with Andrzej, it seems like a lot of work when relatively well-supported / well-documented boards in this same class are so common. Hard to justify purchasing one at random with so much uncertainty about how big the task will be. If i did already buy one, i’d probably be using it to run android apps on my tv and i wouldn’t want to break it for that purpose?
Anyways i’m not terribly optimistic about finding an aftermarket use for my nvidia shield tv when it is no longer suitable for its intended use.
I guess it could quite easily make a MAME box.
PostmarketOS (especially witout GUI) would be a good candidate for an OS here (granted the most work to be done is on the bootloader side of things).
For anyone curious about how straightforward it now is to run Armbian, on what turned-out to be a very good, and not at all dodgy Android TV Box:
https://green.bug-eyed.monster/armbian-on-the-h96-max-v56-android-tv-box/
All credit for development of the Armbian board support layer, for the H96 Max V56 RK3566 Android TV Box, goes to Hqnicolas.
I had little understanding of what Hqnicolas’ development effort involved, before having spent the last 2-months successfully attempting to do the same trick, by adapting the Home Assistant OS to the same TV Box.
You’d better like the prod, compile/ test cycle…a lot. Even first serial output is quite an accomplishment here.
Ummm…you can still run linux and other distributions on TV Boxes, without disturbing the original Android OS, if you like.
Look for these Google Play Store Apps:
UserLAnd
Termux
👽
Would these systems make good network security honeypot monitors?
Absolutely, A number 1! I can have simple install of type software for make possible to you send completely without charges! Please to send email and organizations type for quickly make happen!
On Ebay, there’s a good selection of Chromeboxes that have been converted to straight Linux systems. They make great little linux systems for various projects.
Have we considered preloading these with propaganda and donate them to children in the sahel?
They’re handy – many of them run an Amlogic S905 series SoC. I have one running Tailscale, acting as an exit node – allowing me to VPN through home while travelling. 80mbps throughput with 2.1W of power consumption – not bad at all.