The Steam Link was recently put on sale for $15, and I purchased several of them at that price, because the hardware seems worthwhile to me at that cost.
Shortly after that, during black friday of 2017, the price fell even cheaper to $5. Shipping from Steam directly costs $7, so the overall cost shipped was $12 directly from Steam in the USA.
At such a low price, the Steam Link becomes a device worthy of tinkering with and pulling out its potential. It is only a single core 1ghz device, but it does have a Vivante GC1000 GPU that is capable of basic graphics acceleration. As such it can handle emulating a wide variety of console games.
I looked into making the Steam Link become a lower powered equivalent of a Raspberry Pie device running RetroPie. I found people have already compiled RetroArch and some emulation cores to run directly on the device, thanks to the provision of a SDK for native app development by Valve that was provided 2 years ago ( in 2015 ).
With a bit of hacking I was able to compile EmulationStation to run on the Steam Link as well. It was painful and required monkeying with the build process a bunch, but I was able to get it working. The result of that work is a tarball of the app from my Steamlink: emustation.tar.bz2 Download that and extract it into /home/apps to get it working.
You will note that the provided file is not a tgz file. It cannot be dropped on a usb stick and be picked up by the Steam Link automatically. I will clean up the file and make a version like that soon enough. For now you will need to enable ssh on your device and do the following steps to get it installed:
One of the nice things you can do with the Steam Link is easily enable ssd on it and ssh into it. A lot of basic tooling is enabled there, but many things are also lacking. It does not come with what could be considered the typical GNU toolset.
From a broad perspective, you can consider a Steam Link as just a Arm power device with some custom device connected to the CPU. The specific variant of Arm on it is Arm 7 Hard Float. More specifically Neon with SFP version 3 extensions are supported. Many Linux distributions have binary packages available for Arm7, both with and without hard float. Soft float means that floats are emulated. Hard float means that there is support for hardware floats despite not being 64-bit. So, code compiled for either variant of Arm7 will work on the Steam Link.
What this means is that you can take binary packages from existing Linux distributions, and run them on the Steam Link after extracting them, as long as you also extract all of their dependent binaries as well. Now, optimally, you want to avoid packages compiled against kernel features newer than the Linux kernel running on the Steam Link. Interestingly though, most basic utilities do not care that much about which kernel they are running on.
The process of getting a basic set of packages running on a new device is called bootstrapping. It is well known for many variants of Linux. I found a site online where someone made a bootstrap package set for the Steam Link from arch. You can download that, chroot into it, and run basic Arch. Not only that, you can easily download and run additional Arch packages of your choice with the Arch package manager, pacman.
I decided to take this one step further and bootstrap another OS to the Steam Link. I used Debian, running deboostrap, and was easily able to produce a arm7hf bootstrap package set for the Steam Link. With a bit of tinkering I was able to make package fetch and installation with apt-get work as well.
Will post the full process and steps to doing this soon. Stay tuned.
The Steam Link does an interesting thing when it boots. It checks for a plugged in USB stick and it will install tarballs off that device. Additionally, it will automatically run some code on the USB device as well. This is intended to make it possible to easily add native apps to the Steam Link, enable ssh on it, and run testing of the device ( I assume they do this as a final step before shipping the things out )
What is amazing is that they allow this at all. Many similar device, such as Chromecast, allow no such extensions of the device. Certainly most device prevent you from gaining ssh access easily and monkeying with the internal binaries on the device. The Steam Link does not have those protections.
The bootloader is of course locked. Only a signed kernel from Valve can be run. This means we are stuck on an old kernel for the device, and also forced to use binary drivers for graphics that have no freely available source. Despite that, the rest of the system could theoretically be replaced. You can easily turn the Steam Link into a basic Linux machine, removing the Steam Link software itself and repurposing it to do something entirely different.
I doubt Valve intended for people to do this, but they made it possible. I for one am having fun hacking the thing, and will happily share my research and progress with making the Steam Link a much more useful device.
Root access is available automatically after enabling ssh on the Steam Link. As a result, it should be possible to dynamically reload a replacement Linux kernel instead of the one provided by Valve.
There are two primary ways that a kernel is updated dynamically on Linux. The first is using ksplice. Ksplice is a proprietary method that dynamically patches portions of the Linux kernel as it is running. It is not open source and using it on the Steam Link would be difficult if not impossible.
The second method is to use kexec. Kexec is a Linux kernel feature that allows to to specify a new kernel and dynamically load into it. Unfortunately kexec is not built into the kernel provided by Valve.
Despite kexec not being built in, we are still able to install kernel mods via insmod. Since we can, I believe it should be possible to take the kexec code and compile it as a kernel mod. In all likelyhood a manual kexec can then be done directly from the init routine of that kernel mod. What that would cause is for the kernel to be swapped immediately when the kernel mod is loaded.
It is not clear if a standard kernel compiled for armhf would work properly. Even supposing we can dynamically swap the kernel, it would be good to know what modifications Valve has done to the kernel they provided, and why. Those changes are likely important and would have to also be done on a more up to date kernel for everything to work properly.