These chips are not supported on our current codebase and require the Amlogic 4.9 kernel which is not fantastic - the quality of Amlogic's botch job proprietary code has not improved and the overall kernel has become more Android oriented with time. Also, S905X2 does not guarantee GB ethernet (lots of boxes will use a 10/100 PHY) and while the Mali G31 is more capable than older Mali GPU's the performance increase is largely lost on a simple app like Kodi where rendering is capped at GLES 2.0 anyway.
So the forward path isn't clear yet. For some time our development focus has been on moving away from bug-ridden old kernels and onto a modern codebase, but while Amlogic have been sending patches for G12A platform support to the kernel for a while it's still in an early state and mainline kernel LE images for these boards are not currently possible (i've had hardware for a while). The 4.9 kernel also has a crop of new bugs to find and fix (in addition to loads of unresolved old ones inherited from the 3.14 codebase) and ultimately it depends on amcodec support which exists today but will be removed in Kodi v19 - so it's a load of work with a limited lifespan.
IMHO these devices should stick to Android until mainline kernels are viable, but I daresay users will be pissy with that suggestion and someone on the team will be forced to grapple with the 4.9 kernel mess as a stop-gap. It won't be me though 
S905X2 supports Dynamic HDR10, HDR10, HLG and Technicolor HDR. It's all rather irrelevant though because right now the mainline Linux kernel doesn't support HDR and Kodi is only just adding the first wave of support for all the colourspace, decoding and rendering combinations required. We are in contact with the Intel developers who are planning to submit the initial patches for HDR support soon. Once that patch-set lands and clears initial maintainer reviews we can start work on adapting the new Amlogic DRM driver to the same kernel frameworks and finish integration with Kodi. This means it will not be until K19 that Kodi (on Linux) truly handles HDR and other new formats correctly. Until then support is a string and duct-tape job based on educated guesses about how the as-yet undefined upstream kernel stuff will look like. The older 3.14/4.9 kernels + amcodec are similar (but with different bugs) due to HDR support being added long before there was any kind of standard to follow. In both cases the result is something that "works" but has numerous gaps.
