Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
63 
Report this post
You can discuss retroarch freely im pretty sure
Second, from what I could tell, there is nowhere near enough resources on the Link to pull this off. RAM is the most limiting factor let alone limited user available storage space.
And by nature of a chroot, I don't believe Arch would have access to the graphics hardware to even get going.
Emulationstation/RetroArch are definitely doable but it'll have to be done without bringing Arch/chroot into the mix.
I don't think compiling most things uses as much RAM as you are speculating though.
Latest updates are essentially that I have failed to get the graphics drivers working in any way within a chroot skipping the custom stuff. The only way I see it could even be possible at this point is to use the old etna_viv on github and work directly with the /dev/galcore device.
I was able to build libdrm to use vivante, but ultimately after investigating thoroughly, you need support in the kernel. Linux kernel 4.something imported the whole of etna_viv in, and all of the modern stuff requires the kernel support to be there. Not only that, but there is no framebuffer support in the kernel steam has provided, so you can't even output graphics via a framebuffer.
Really the only reasonable solution for a modern software stack is to convince Steam themselves to rebuilt the software stack on a newer version of the Linux kernel.
If they are unwilling to do that then it would be nice if they at least enable some more options in the kernel version. Things I would like to see: framebuffer support ( # CONFIG_FB is not set ), kexec enabled so that we could dynamically load in a new kernel ( # CONFIG_KEXEC is not set ), swap support -- perhaps no swap is possible currently? ( # CONFIG_SWAP is not set ), DRM support ( # CONFIG_DRM is not set ).
On a good note, I have been able to get Debian running in a chroot similar to to how parkerlreed has arch working. I had to spin up a Debian VM and run debootstrap, but was relatively easily able to generate a 35mb tarball that is functioning Debian on the Steam Link with a chroot.
I think there is a possibility of using natively built packages and/or prebuilt debian packages in combination with the existing libraries and binaries on the steam link. You don't -have- to use a chroot. I modified PATH and LD_LIBRARY_PATH and am able to run, for example. gcc, perl, make, and vim all without doing a chroot. I realize there could be API incompatibilities between the built pieces. I am essentially just saying "try to use the steam link binaries/libs first, then use the debian ones if what you are looking for isn't there." It seems to work...
My hope is that it is possible to figure out what is breaking some of the additional emulation cores, and replace the native binaries/libs with ones that are more up to date.
Just for the heck of it I attempted to get X running; and that is just a giant pile of madness. I am going to give up on that ridiculous and comical goal for a while.
Sorry to anyone waiting around for my built/working version of EmulationStation. I have been very distracted thinking and trying other possibilities. I was hoping to build a better version instead of releasing the hacked up version I created so far. I think we are probably stuck with the hacked up version for the time being though.
I got it running thanks to the great instructions on your site!
I am really eager to hear if the Kernel can be changed to avoid sound problems that
happen after playing retroarch for a little while.
The emulation is so great for so many games it would be a shame if this barrier can't hurdled.
I have a few inquiries any insight would be greatly appreciated!
1. Is it possible to make steam link boot emulation station?
I am mounting my usb key on boot via information I found here:
https://steamcommunity.com/app/353380/discussions/1/343787920122841325/
Based on this, I figure there must be away to automatically boot the Emulation Station app on boot?
2. Is it possible to recompile Emulation Station with a different boot image? If so would anybody be willing to share the steps required to do this? I would love insert a custom image on boot at this stage the boot screen appears for quite some time.
3. I would like to kid proof the Emualtion Station interface so they can't accidentally delete games etc... Upon recompiling would it be possible to hide options in the main menu... EX:remove scrape, I stumbled upon a delete option I would like to disable etc....
4. Is it possible to make Emulations Stations "Scrape Data" be contained on the usb key that is mounted? I have a wack of games and I am worried scrape data will fill the internal memory.
5. When steam link boots it has an image that implicates a controller needs be connected. Wondering if the image is free floating in the existing files structure and can be replaced?
If not, it would be cool if a new Kernel could swap the image.
6. It is super annoying that steam link always asks to be connected to a network upon boot. I know it is designed to connect to a network and this is the intended design. I am hoping there is a way to disable the network prompt that asks you to connect to wireless networks? I want to use the device as a standalone box that only bothers to connect to network if I specifically go into the options and trigger the command.
Sorry for all the annoying questions. I figured I would ask.
1. Possible to auto-run Emulation Station on boot?
I think it is possible. The boot process can be altered readily. I haven't altered it yet because I didn't want to risk bricking my steam link initially. I now have several thanks to sales so I will look into this. It is one of the easier things to accomplish.
What I am not clear on is whether the Steam launching interface is required at all. To my understanding USB controllers are not using the steam interface; instead just acting as normal Linux USB devices within EmulationStation/Retroarch; but I am not sure how that is actually setup.
Trial and error would show. What is required is to figure out which processes on the Steam Link do what, and to disable execution of the ones that are not needed; and then instead run EmulationStation.
Do be aware that removing the normal functionality of the Steam Link by installing an App is likely not something Valve wants. I don't think they sell these things cheap to use for other purposes. The mentality, I believe, is that running other apps is fine so long as people also use the Steam Links for the intended purpose of playing purchased Steam games.
2. Change EmulationStation startup image
The image is just data. It is sitting in the source folders somewhere. It could easily be changed before compile. It is likely possible to also configure it to not be embedded in the exe with some minimal changes to the code. ( perhaps some configuration to use a different image already exists within its config as well )
3. Disable various EmulationStation features ( scrape/delete )
Disabling various options within EmulationStation shouldn't be too hard of a change either. The only trouble here is that you would need to use a non-scrape disabled version to do the scraping and then swap to one with scraping enabled. That wouldn't really be hard to do though, you would just need to swap the exe files over ssh.
4. Store scraped game information on USB drive
This is assuredly configurable, and I agree is needed for reasonable usage. The internal memory of the Steam Link is not that large and images and such for reasonable game collections will quickly eat it up.
The script to start EmulationStation should be altered though to automount the USB stick when starting it. I didn't bother yet because it is just a demo of it being doable; but a proper installable app for EmulationStation can easily be made to do that. I will look into and do this.
5. Change Steam Link "plug in a controller" image
Pretty much anything on the Steam Link that is not the kernel can be changed easily. It is just a matter of tracking down where the image is.
The only difficulty about swapping things out on the Steam Link is that the boot process mounts image files as folders. The system is not just a flat filesystem where you can easily replace anything. Some of the mounted stuff is mounted readonly. I think remounting as read/write works and lets you alter the files though ( I did so once and it seemed to work )
6. Disable "connect to network" on boot of Steam Link
As mentioned above, the entire boot process can be altered easily aside from changing the kernel ( which can also be done but will be more difficult ). The trick is figuring out which things can be disabled and not lead to the Steam Link being in a broken state.
I don't see any reason why it should not be possible to get rid of this. It may not be possible to get rid of it without also skipping the Steam Link launcher interface entirely. My guess is that it is built into that interface.
Once again; disabling the Steam Link interface is likely frowned upon by Valve.
It is probably over my head but I am interested in attempting to make an EmulationStation build that hides some options / changes the boot screen. Would you be able to describe the build process you used to get the EmulationStation compiled for the Steam Link?
Hoping to get a hold of your source files as the basis for my build attempt.
I know alot of blood sweat and tears went into your build so I understand if it is too much work to describe the details of the build.
I made a file containing my basic build changes/parts for building EmulationStation. You can get it here: https://livxtrm.com/steamlink/emustation_build.7z
Within the steamlink sdk, under examples, I have the contents of this 7z file extracted as a folder.
At the root, there is a modified build_steamlink.sh file. It is based on the existing one for retroarch. It is modified to have the sdk at /root/steamlink-sdk. Within all of my files and changes you will need to modify that hardcoded path to wherever you have the sdk deployed. I did not make it clean and use a shell variable.
You will see in the build file I have placed boost, eigen, and FreeImage libraries at steamlink-sdk/libs/...
Building those libraries properly is a thing in and of itself which I will need to document separately.
Note also the 'configure' link is commented out in the build. It is commented because I ended up trying a lot of different variants. I don't seem to have the correct configure line on hand and will need to rerun configure myself and tinker to recall what should be used.
The changes to the emulation station source code I dumped into 'emustation-src/emustation.diff'. ( in the 7z file above ) Once the source is downloaded ( of EmulationStation, which the build script should do ) you should be able to apply this diff file. Note that the diff file has those hardcoded paths to /root/steamlink-sdk once more. ( and note also you really shouldn't use the root user to build stuff... I have since moved the sdk myself but didn't update my build files yet )
The changes are just hacks to the cmake library detection to force them to work. There are better ways to do this but I just hacked them to get it done in as little time as I could.
I also created a pkg-config folder, and set the PKG_CONFIG_DIR shell variable to point to this directory to get the build to pickup FreeImage.
This should get you started with rebuilding EmulationStation. As said; will update with the additional information on how to get the libraries to build.
ES for Retropie
https://github.com/RetroPie/RetroPie-Setup/wiki/Debian
ES for windows
https://ci.appveyor.com/project/jrassa/emulationstation/history
ES for devian
https://github.com/RetroPie/RetroPie-Setup/wiki/Debian
Here is a Theme that I think is fantastic,
https://retropie.org.uk/forum/topic/12583/snes-mini-theme
With this, if I can help. I could modify it theme steam style, with other icons more in line with steam link. It would be great . Also use simple loading screens as retropie. I dream of all this in my steam link
http://steamcommunity.com/app/353380/discussions/1/1482109512299476145/
That is to say: it could be installable at the beginning as a .tgz file. also as this retroarch 1.6.7 can be added cores and roms in a usb. I hope you explain me well. Do not program if you do not try it myself, but maybe it's a good way. so it could be that the retropie themes worked and it was easy to add roms and cores. Greetings and thanks for your work.
The farthest I got so far is running bootstrapped Debian using chroot. I additionally spent a while attempting to avoid using the binary drivers for the GPU provided in the SDK. What I discovered was that using a kernel with the new etnaviv drivers enabled in the kernel is required in order to do that.
The next step is to replicate the steps already done to make a kexec'able kernel, ensuring that the etnaviv drivers are built into the kernel that is built. From the description of the kexec so far, it sounds like the kernels that have been tested do not have that driver built in, as I have not heard that anyone managed to get GPU output from such a setup yet.
Really it is fine to use either Arch or Debian as the distribution selected. There are difference but either should work.
Since I have not yet run the kexec setup, I am not totally clear on it so far. Specifically I would like to know what happens when the kexec occurs. Obviously the kernel is loaded, but I am not clear how the system knows what device to use as the system root. I don't have a deep understanding of the initial boot process so I am not clear how one configures the root.
That is, in the kexec setup demoed so far, does it just boot whatever Linux filesystem tree is at the root of the USB stick? If I build a different kernel with different options, and swap out the kernel file, will it continue to do so?
Is there any simple list of steps to follow to build a Linux kernel with different options for the Steam Link such that it will work with the kexec insmod? Importantly; what compiler should be used to build such a kernel? Was the SDK provided compiler used to build the Linux kernel? If so, shouldn't we instead use a newer compiler?
I spent a while attempted to build a different compiler. I found some websites that explained how to do it and spent some hours going through the guide, and was able to do it fine. I would prefer to use a more automated process to choose a compiler that is setup correctly though, as I don't want to repeat that process multiple times upon discovering I want a differently compiled libc etc.
Can I use any libc with the debian armhf repositories? Can I choose any random Linux kernel build options and still ahve the debian armhf repo binaries function with it? How do I know which options I can change and which I cannot? Do we even know exactly what hardware the Steam Link is running? Has anyone carefully thought about what drivers are added manually as modules in the Valve provided setup overtop of the normal open source stuff in the kernel? I know I see other binaries provided without source besides the GPU ones. Are we going to encounter more problems with components on the Steam Link without open source drivers?
I figure the following main subsystems need to work:
1. The CPU itself and whatever features it provides. To my understanding so far, all that needs to be known here is that it is armv7a with hard float.
2. The memory. Since it already basically works, I am assuming the memory controller and amount etc is supported and works fine.
3. The GPU. To my understanding from reading many random pages, we can just use a new kernel with the etnaviv drivers upstreamed into it. Not sure if they need to be enabled during the kernel build somehow or not. Probably so.
4. The sound. Will the sound automagically work once the GPU is supported, as the sound can go through the HDMI? Is there a separate sound chipset on the device?
5. The USB ports. As I understand it, the Linux filesystem being used after kexec is on the USB stick. As a result, I assume that the USB system is standard and supported by recent kernels.
6. The ethernet port. Once again, the explained result of kexec is that you can ssh into the resultant booted Linux system. This would require that the ethernet does work. I don't know though if anything special was done in building the kernel to ensure the network drivers work correctly.
7. The wifi. Is the wifi standard? In the demoed kexec setup, does the wifi function?
So very many questions, and so very few answers so far.
My assumption is that the kexec setup demoed essentially works, that once etnaviv drivers are enabled in the kernel the setup will be essentially easy to build everything and leave the Steam provided SDK behind entirely. There could be many roadblocks in the way of doing that.
It turns out that people have already done this before. It was done for the Amazon fire 2 years ago and there is a github repo here with code: https://github.com/chaosmaster/ford_kexec
Lukas Schauer on the Reddit Steam Link forums ( lukas2511 ) took this code and "tweaked it slightly" to make it work with the Steam Link. The slightly modified insmod kexec code can be found here in the github repo that he made: https://github.com/lukas2511/steamlink-sdk/tree/master/ford_kexec
Lukas's Reddit post can be seen here:
https://www.reddit.com/r/Steam_Link/comments/7ixxb2/boot_own_kernel_on_steam_link_kexec/
He mentions in his reddit post that graphics do not work currently.
There is a simple reason: He did not enable the kernel driver for the Vivante GPU.
The kernel driver config line is "CONFIG_DRM_ETNAVIV"
( see https://cateee.net/lkddb/web-lkddb/DRM_ETNAVIV.html )
If that line is added to his '.config' file and the kernel is rebuilt, and the process he gives instructions for is followed, graphics should output.
He does not provide instructions on how to rebuild the kernel. I saw instructions on how to rebuild the Valve provided kernel somewhere here in the forums. Perhaps those same instructions can be tweaked slightly to build a new kernel? Or someone could just contact Lukas and ask him to add the config line and rebuild. ( I have now contacted him and let him know )
Note that if the instructions Lukas has are combined with the method I described to chroot to Debian, one could in theory install the 'xserver-xorg-video-armada-etnaviv' debian package to get X working on the Steam Link. ( assuming a kernel was kexec'd to that had CONFIG_DRM_ETNAVIV set in its config )