Linux Kernel FAQ and Discussion

The subject of what kernel CoreELEC uses (and doesn’t currently use for example the mainline 5.x kernel) keeps popping up in other threads and ends up going in directions that get more and more off-topic for those threads. I also find myself answering very similar questions often.

So I decided to start a thread to continue the discussion, so that there is one place to have that discussion. Please keep it polite.

The 4.9 vendor kernel current used by CoreELEC.

CoreELEC currently uses the 4.9 vendor kernel maintained by Amlogic. This kernel has a vast assortment of extra features and drivers added to it by Amlogic to support their various SoC. (This is referred to as a vendor kernel because it is developed/released/maintained by the vendor for the sole purpose of supporting their product.) This is the only maintained kernel that has working support for the hardware decoder and all the other media features provided by Amlogic SoC(such as HDR). Almost all advertised features of most Amlogic based devices work with are supported and work with this kernel as used by CoreELEC.

The 3.14 vendor kernel.

CoreELEC has also in the past used the 3.14 vendor kernel that was previously maintained by Amlogic. This kernel has for a long while seen no further development or maintenance from Amlogic. The upstream LTS(Long Term Support) period for the 3.14 kernel also ended in August of 2016.

The 3.14 is now 7 years old, so beyond ancient. Which makes it very difficult and time consuming for the CoreELEC developers to work with. After much discussion between the CoreELEC developers it was decided to stop using the 3.14 vendor kernel for releases of CoreELEC after the 9.2.x release became the legacy release. With much Regret this has currently left the GXM(S912) and GXBB(S905) based devices with out support in the next CoreELEC. (Both of these SoC families are 5 years old and currently EOL by Amlogic)

I saw GXM(S912) device trees in the 4.9 kernel source. So why can’t it be supported?

The 4.9 kernel actually works great with S912 devices, with the exception however of one major show stopping problem. There is no publicly available linux drivers for the Mali-T820 GPU that the S912 SoC uses. In short no driver == no GUI. No GUI tends to make for a rather poor user experience with a media center.

Some might remember kszaq’s hack that was done to make the Android GPU driver work with the 3.14 kernel. This unfortunately does not work with the 4.9 kernel. Myself and at least two other CoreELEC developers spent a considerable amount of time(Probably several hundred hours in total) trying to figure out how to make the S912 devices work with the 4.9 kernel used in the CoreELEC amlogic-ng builds. Keeping in mind here that we are volunteers and this is a hobby in which our time is not paid for.

To the best of my knowledge none of the companies that produced S912 based devices ever released an updated Android firmware using the 4.9 kernel. Which is a problem since the hack depended on files pulled from Android to work. So even if kszaq was available and willing to help with this, there is not much that can be done without the files.

What about the Mainline 5.x kernel?

While the upstream linux developers have made some pretty great progress. It’s still a really big task to fully support one new SoC, let alone multiple families of SoC. So this work is still not complete.

Progress on mainline however doesn’t happen quickly.

Unfortunately some of the missing and unfinished parts, are the parts most needed for a media center.
For example the mainline 5.x kernels do not have working support for the hardware decoders that are in the Amlogic SoCs.(Yes this work has been started, it’s just not complete enough to be used as more then a curiosity) Mainline also doesn’t support features such as HDR on Amlogic devices.

As far as CoreELEC using the mainline kernel. The developers don’t have Ideological considerations when picking a kernel to use, so any actively developed kernel that can provide the required feature set is an option to be considered. However as stated above the mainline kernel currently doesn’t provide the feature set required to see it used in an official stable release at the moment.

(I will add to this thread as I get time to do so. If I spend all night writing a novel length posts I won’t get any actual testing/development work done. :grinning:)

14 Likes

[reserved]

Current state of Mainline 5.x kernel as of version 5.11

Basic hardware support is fairly good. There are still some missing / unfinished things, a number of devices don’t currently have device trees, or don’t have device tree entries for all the included components.

GPU support is good enough for kodi’s needs when using the 5.11 kernel and a recent mesa 21.1.0-devel version. While it doesn’t have the performance of the Mali binary blobs from arm, and is still missing some features. This is at the point of being more then enough to keep the kodi GUI feeling snappy.

Audio still needs some work for more advanced features/formats, and the headphone jacks, I2S DACs, SPDIF on many devices are not currently configured, or maybe missing stuff to make work. Dropouts and other issues also occasionally happen.

HDMI support has the basics in place, there is still some missing features that some users would miss and the odd bug. HDR is not currently supported.

Video Playback is very much a weak point with this kernel. While there is the start of support for the hardware video decoder, it doesn’t work so great, is not reliable, and only a few codecs are currently supported(pretty much h264). It also can’t handle some of the odd quirks that are found in a lot of actual content people use. 10bit, HDR, are all not an option. There are also currently some audio/video sync issues, seeking doesn’t work, and a lot of encoding artifacts get shown. Video playback is also not always repeatable, in the sense that some files won’t play after some other files are played.

CEC, I have no idea about the status of CEC. I don’t have any devices that support it, and would probably avoid using it if I did.

DVB, there is more external DVB adapters supported, however there is no support for most of the internal DVB that Amlogic devices tend to have. Not that this makes much difference until the hardware decoders are working.

WiFi/Bluetooth, some devices have a bit of a win here due to newer drivers, however other are at a loss since there is not support for all the same WiFi/Bluetooth chipsets in the mainline kernel as there was with the 4.9 vendor kernel.

This is not everything and is a little light of technical details, but I think that covers most of what people would be interested in, and some of the reasons the CoreELEC developers feel that the mainline kernel is still not an option for making releases with.

5 Likes

IIRC the CEC driver in mainline is pretty good. Using CEC Framework.

Great summary, thanks!

Similar to “I saw GXM(S912) device trees in the 4.9 kernel source. So why can’t it be supported?” I have a question:

“I saw GXBB(S905) files in the 4.9 kernel source. So why can’t it be supported?”

I assume those are just leftovers from older kernels, and support got removed, right?

@ashi your answer to

“I saw GXBB(S905) files in the 4.9 kernel source. So why can’t it be supported?”

Amlogic decided not to continue supporting this older SoC early in their development of the 4.9 kernel. There is some consideration for GXBB(S905) in some parts that they added but as you assumed this is left overs from previous work ported to the 4.9 kernel. (Some of the code mentioning GXBB(S905) is also actually code that was already present in the kernel from community efforts before Amlogic started development on their version of the 4.9 kernel, and doesn’t work with the code Amlogic added.)

So in short there just isn’t enough of the code that would be required to to make it run included in the kernel, and it would be a lot of work to add the missing stuff.

Now some will remember hearing that GXBB and GXL are somewhat related, and do share some of the code that is required to support them. Which is a bit of a start to getting the 4.9 kernel booting on the S905. However not nearly enough is shared, and there is a lot of places in the GXL code paths that you need to account for these differences as well. I made an attempt at creating the missing device trees and filling in some of the missing bits for the GXBB(S905). Unfortunately close is not close enough, without a lot more time, effort, and documentation then I had available.

There is also a good chance too, that even if you got it booting that you would then encounter two further problems.

One, the Amlogic media modules(The drivers for the the video decoders, etc…) have been being developed with no consideration for GXBB(S905) support for years now, and would probably take their own extended effort to make work properly with the GXBB(S905).

Two, the 4.9 vendor kernel has issues working with the older versions of the vendor uboot that likely was used on these older Amlogic devices. So A lot of effort could go in for something that may still not even boot on the majority of GXBB(S905) based TV boxes. (Some GXL devices have this issue as well, if they don’t have at least the version of the vendor uboot that would have been used with an Android 7 or newer.)

1 Like

Thank you for explaining this!

I was convinced that 905 and 905X/D are 99% identical before. The reason is linux-meson.com, the mainline effort. They write things in a way which suggests they are almost the same while they are obviously not.

GXL : Quad 64bit Cortex-A53

S905D : Similar as S905, but with internal 10/100 Ethernet PHY (Gigabit Ethernet still requires an external PHY)

I tried the libreelec master branch with mainline kernels on S905, but every time I did, the video decoder completely died when trying to seek a video. Plus H265 isnt there at all. Still it is probably our best bet for S905 boxes in the future.

Thanks again for all the great work, I am happy that I can use the 4.9 vendor kernel on Matrix on my main 905D box :slight_smile:

Well that is a problem that can happen when you are trying to write technical things for a general audience, you end up having to gloss over the details of some of the really technical parts. Which in this case, is where most of the difference between the two SoC is.

About | FAQ | Terms of Service | Privacy Policy | Legal Notice