Instead of cluttering up the Emulation Station topic with stuff related to using a new kernel and video card drivers; I will add information under this topic.

It is possible to build the latest stable Linux kernel ( 4.14.14 ) and kexec into that built kernel using a kexec code loaded via insmod.

When doing that, a dtb/dtsi file needs to be used/created to match the hardware of the steamlink. New Linux kernels have an open source 'etnaviv' driver that supports the GPU on the Steam Link. In order for that driver to properly know and use a GPU, it has to be told information about that GPU.

The information it needs to know is the memory address the 2d and 3d portions of the GPU are at ( called 'reg' ), the interrupts each use, and the clocks ( the clockspeeds that the different parts of the GPU run at ). Unfortunately there is no clear way to get this information. I have been trudging through the Valve SDK kernel source, and the only information is the dtb/dtsi Valve uses.

The dtb/dtsi used by Valve does not contain information for the 2d address and size. It only contains a 3d entry. Additionally, since proprietary binary drivers are used, it doesn't specify the clocks in the same way.

The Valve dtsi file used can be seen here:
https://github.com/ValveSoftware/steamlink-sdk/blob/ce30ba161aa03a4f5564a636ac237f58fd42a68b/kernel/arch/arm/boot/dts/berlin2cd.dtsi
As can be seen, no clocks are specified there.

A similar device that does share a related GPU is the Chromecast 2. Fail0verflow was able to get the etnaviv drivers working on that acceptably. See their post here: https://fail0verflow.com/blog/2014/hubcap-chromecast-root-pt2/ In the conclusion it is mentioned they have graphics working with the etnaviv driver.

The Chromecast 2 uses the Armada 1500-mini plus chipset. It is very similar to the 1500-mini used in the Steam Link. It is possible that the dtb/dtsi settings used by fail0verflow will work for the Steam Link. They don't seem to have posted that information anywhere online. Someone should ask them what information they used. It would be a decent start.
( edit 1: I am asking them )

Edit 2:
The way that the proprietary Vivante drivers work compared to the open source etnaviv drivers is very different. It is unclear how to translate the Valve SDK dtsi configuration into dtsi for the etnaviv drivers. The memory addresses and irq should transfer across, but the 'clock' information is confusing and I don't understand it.

Additionally, I don't see examples of Vivante binary drivers being run on Linux 4.x. The drivers would need to be ported to even run on Linux 4.x. I am beginning to think that the most sensible way to "update" the Steam Link is to run a newer version of Linux 3.x and/or one with more kernel options enabled. That could perhaps address the bugs that are seen, or at least provide the ability to debug in more depth what is going on when the graphics start lagging.

At the very least, if the old kernel version is used, then the proprietary open source Vivante kernel drivers could be altered to dump out more information, and then loaded in the kexec'd newly built kernel. It is not safe to replace the actual graphics driver on the Steam Link because that risks bricking the device.

To begin building an updated Linux kernel, the start is to get the Linux source without any changes by Valve, and then compare it against the Valve SDK release to ascertain exactly what was changed. Then those same changes can be ported to an updated 3.x Linux kernel.

The kernel run on the Steam Link currently is 3.8.13. That kernel was last updated in May of 2013. The most recent 3.x version is 3.18.92. It was updated this month. There are essentially 4 years of updates to be had. Those updates could also break compatibility with the Vivante GPU kernel drivers, but it could at least be attempted.

Another task of interest would be to try and copy the standard filesystem of the Steam Link out to USB, and attempt to boot a working Steam Link environment with an updated kernel, instead of attempting to use a different distribution. Could be problems with this as well but it would be interesting.

I had an idea to see the screen, we could setup vnc server on the debian bootstrap then connect to that through vnc on windows/mac, it wouldn't be the best setup but it would work

I've been playing around with this a little. I don't think an updated kernel is an option directly on the device due to signing. There's stuff out there already where you can load ArchLinux 4.x from a usb though. Not entirely sure what I'm planning with the Steamlink yet, but probably going to try to modprobe video drivers with an update if I can get that far. Wondering though if this is what you were looking for as far as IRQ, memory, and Freq, and if there's still any interest in hacking the device, or if everyone moved on.

[ 13.409493] Galcore version 5.0.11.17486
[ 13.409498] gal3d options:
[ 13.409501] irqLine = 37
[ 13.409505] registerMemBase = 0xF7BC0000
[ 13.409509] registerMemSize = 0x00000800
[ 13.409512] contiguousSize = 512
[ 13.409516] contiguousBase = 0x00000000
[ 13.409519] bankSize = 0x00000000
[ 13.409523] fastClear = -1
[ 13.409526] compression = -1
[ 13.409529] signal = 48
[ 13.409533] powerManagement = 1
[ 13.409536] baseAddress = 0x00000000
[ 13.409539] physSize = 0x80000000
[ 13.409543] logFileSize = 0 KB
[ 13.409546] recovery = 1
[ 13.409549] stuckDump = 1

gfx3DCoreClk frequency 425
gfx3DSysClk frequency 425