Steam Link

Steam Link

Vivante Driver Source
The graphics driver used on the system and provided in the SDK is only provided in binary so format. As such there is no way that I can tell to rebuild it.

I am rebuilding an entire stack on the device itself, which seems doable for most things but this is a blocker to replicating and making a more up to date system.

Please provide one of the following if possible:
1. The source code used to build /usr/lib/libVIVANTE.so ( along with libGAL.so and libEGL.so )
2. Some way that the existing binary files can be used with other rebuild dependencies. I attempted to use the existing files with a built arch linux set of /usr/lib, and they don't function together. How can I possibly build an updated system if I am stack with the exact binary stack of /usr/lib?

I am attempting to work around the lack of being able to use libVIVANTE, but it would be nice to be able to replicate what is being done currently.
< >
Showing 1-5 of 5 comments
Vivante is proprietary. If you want it open, you should use etnaviv.
It's pretty common to have those libs are binaries.
But are you saying the remainder of the steam link is open, because I highly doubt that.
Yeah I have been attempting to use etna_viv / etnaviv for a while now. I haven't been able to get it functioning on the steam link. Most people have abandoned using it by itself since it has now been upstreamed into the linux kernel itself.

Really I just want to know which specific files are the proprietary pieces for the graphics driver and what their dependency tree / so apis are. If I know that I can reuse the prebuilt binaries with the rest of the system replaced. I think the answer to this is libGAL, ligEGL, libVIVANTE, and libOpenGLESv2. The problem is each of those depends on a pile of other system libraries. If I have newer versions of the system libraries with a different API under those, the dynamic load is going to fail.

I suppose it is possible to hack up the binaries and point them at copies of all the underlying dependencies... ( eg: alter the dynamic load to different names, so that just those libraries use the full original steam stack ) That should work?

I agree a lot of the steam link is closed source still, but I think the rest of the hardware itself has easy open source stuff available.

Really the point here generally is if I am going to be hacking together / building stuff on/for the steam link I'd like to use all new versions of open source everything, rather than use the very dated dev stack that valve has provided / is on the steam link.

edited - More random info about this:
The graphics kernel source is at least provided on device and in the SDK. That is legally required of course... but can be found here:
/rootfs/kernel/arch/mach-berlin/modules/gpu3D and gpu3D
Those are running as kernel mods on the device as gfx and gal3d ( do an lsmod )
This looks to be the same / similar as the stuff here from Freescale originally: https://github.com/Freescale/kernel-module-imx-gpu-viv
That would imply that it may be possible to at least recompile the new github contents ( assuming there are any improvements ) and replace the kernel mods on the device with newer ones.
Heh, I'd rather try to run the steamlink binary on my odroid, since that's way more powerful. But that will never happen, as the steamlink binary does a lot of hardware specific access. It's not build on standards :-(.
Anyway, I admire what you are trying to do, but there are not a lot of ARM SoC manufacturers that really are committed. And Samsung doesn't sell to just anybody, because if they did, it would take away a lot of these problems.
Yeah agreed. If it was possible to buy a device similar to the Steam Link but with an unlocked bootloader for $30, it would be a quality competitor with Raspberry Pi. For $30 it would need to be quad core 1ghz. ( which I think is reasonable and can be built at that cost )

I have generally tried to find devices that can compete with Raspberry Pi, but there are very few. What I like specifically about the Steam Link compared to a Pi, or ODroid, or whatever other embedded developed boards is:
1. It has it's own sturdy case around it; I don't have to buy one separately or worry about overheating.
2. It has 3 usb ports. This is actually pretty handy.
3. Tons of people have them already, so there is a chance to have wide exposure and use of anything developed for it. Few people have ODroid in comparison.
4. It has some scripts on it already in the purchased form that let you install stuff by just putting a usb stick in the device and turning it on. This may seem like a silly feature but it is very valuable for the common Joe and enables higher use of anything that is developed.
I know i'm a bit late but,
the problem of running etnaviv is simple: There is no device specification inside the Device Tree.
If you look at the serial console logs, all parameters getting parsed via uboot to the kernel.
since we are using kexec to load our custom Kernels, those Informations getting lost.

Sources:
(decompiled) Steamlink Device Tree: https://pastebin.com/7HwvYmWK

serial console logs: https://forum.doozan.com/read.php?8,46664,page=2

example iMX device tree section: https://stackoverflow.com/questions/58936254/how-to-enable-etnaviv-drivers-without-using-yocto-build

etnaviv Kernel Documentation: https://kernel.googlesource.com/pub/scm/linux/kernel/git/mchehab/linux-media/+/media/v4.7-2/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt?autodive=0
< >
Showing 1-5 of 5 comments
Per page: 1530 50