Linux Kernel FAQ and Discussion

Development Development & Testing
3

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.

  • SM1 (S905X3)
  • SC2 (S905X4)
  • S4/S4D (S805X2, S905W2, S905C3, S905Y4)
  • T7 (A311D2)
  • ??? (???)

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 …

4

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
5

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

6

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?

7

@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
8

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:

9

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.

12

Please read this topic, pose the questions you want after it.

1 Like
13

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?

14

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

3 Likes
15

I’m wondering what this patches would bring any good? What is missed?

16

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:

IMG_20210701_180329
IMG_20210701_1803294372×2850 1010 KB

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.

17

This is the CoreELEC forum, not LibreELEC nor Lakka forum.

18

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.

19

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.

20

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.

21

For CoreELEC it doesn’t mean anything, nothing has changed.

22

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

23

I got it. Thanx.

24

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.