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. 
)
The 5.4 vendor kernel.
The CoreELEC team is currently looking at Amlogic’s newer 5.4 vendor kernel. This is the kernel that Amlogic is currently actively working on.
The SoC listed below are currently supported by Amlogic with their 5.4 kernel.
Note: This list is just for general information about this kernel and does not mean anything in regards to CoreELEC support of any particular device.
There are a lot of parts that need to go together to get everything working (Especially to the same level of working as the 4.9 kernel is) with the new kernel and new devices based on new SoC families. I will try to add more info here as I get time and maybe give a general idea of what is involved in getting a new kernel running under CoreELEC’s hood as well.
… To be Continued …
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.
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.)
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 
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.
Please read this topic, pose the questions you want after it.
I noticed the kernel 4.9 that is used is on like 4.9.113 while the current sublevel is at 4.9.272. Whats the reason behind these patches not being applied and does the LTS really even matter when using the 2018 sublevel anyway?
The AMLogic kernel is not a pure Linux Kernel and so what happens with normal Linux support is irrelevant. This is a special kernel released by AMLogic for their own hardware - and generally it is a single release with very few updates to deal with critical issues in their hardware support.
CE uses the AMLogic kernel and this is why it is completely out of sync with the 4.x series of Linux kernels.
CE will only ever use the AMLogic kernels, unless a fully mature current mainline kernel is released with full ARM AMLogic support. This has been just around the corner for three years now and seem unlikely to ever happen to a usable level for a media player.
Shoog
I’m wondering what this patches would bring any good? What is missed?
HI,
Thanx for the explanation about versions of kernel on Amlogic SOCs.
About developments on Kernel 5.1, I have a question.
I have a T95Z Plus box, which is S912 SoC. Recently, I tried Lakka 3.2 using “meson-gxm-khadas-vim2.dtb”. I know that Khadas VIM 2 is a different device, but it gave the best results, got me in the GUI of Lakka. Just GUI only, and DS3 controller over USB working so that I can traverse the menu, no network.
Here is a screenshot:
As Lakka 3.2 is based on LibreELEC9.2, the kernel should be 5.1. Does that mean S912 SoC runs with kernel 5.1? I know very little about kernel. Thanx for any explanations.
This is the CoreELEC forum, not LibreELEC nor Lakka forum.
Hi,
I am not asking support for anything, such as Lakka or LibreELEC. I am talking about running kernel on S912. If Lxxka or LxxxExxxC are forbidden words, I am sorry.
Discussing them is not forbidden, it’s simply not in the scope of this forum.
The main technical limitation of S912 for CoreELEC is that there is no GPU driver available for the kernel we use. In 3.14 kszaq has managed to hack a solution together, by using the Android blob. Although it was sub-optimal, it worked. We could not get it working on our 4.9 kernel, therefore we have discontinued support for this SoC.
The mainline Linux effort is concentrated on supporting all hardware, including the S912, by reverse engineering and creating a completely new, open source and mainline compatible driver for the Amlogic GPUs.
So technically, the S912 can run the CE 4.9 kernel, you just wouldn’t have video output. That makes it useless for a media center OS.
Thanx for your explanation.
I knew there is some limitations in kernel drivers on S912 from reading the top post. And S912 support of CoreELEC was discontinued as new kernel introduced. Then I found I can boot Lakka (with kernel 5.1) and have GUI on S912 box. I was wondering does that mean the limitations no longer exists for S912? That’s my question.
For CoreELEC it doesn’t mean anything, nothing has changed.
Having a functional GUI is only a part of what a media center of required to do. The bulk of the heavy lifting is done by built in hardware decoders which are not essential to GUI functionality and so are often the last part of the kernel which receives attention and will often be hard to reverse engineered
Without these hardware decoder drivers all the decoding has to be done by the CPU by none optimized software decoders which stresses the CPU and drags overall performance down - often to the point of unusability.
Shoog
About | FAQ | Terms of Service | Privacy Policy | Legal Notice
