Why the old kernel?


I do not currently own a Vero 4k, but Raspberry PI’s (1 & 3).
Now OSMC on the Raspberry’s run on linux 4.9.

However it seems the flagship product Vero 4k runs only a 3.14 kernel. 3.14 has no upstream kernel.org support, and in fact the release used is 3.14.29 [1], from January 2015 [2]. Even the AppleTV build runs on a kernel newer than that.

I assume that the HW vendor only supports 3.14(.29), and therefor that’s the only kernel we are able to run. Is that a correct assumption?

Now, did I misinterpret the build scripts? Is Vero 4k actually running a recent kernel? How is that not a problem and why would I buy a device that the HW manufacturer already abandoned?

I would like to support OSMC and I would like to buy a flagship product. But if using the flagship product implies running outdated, unsupported two and half year old kernels on a already abandoned board - then I simply cannot buy it, as it feels like going back to the old days.

I guess we can’t have the recent technologies like H265, VP9, 4k and HDMI2 without going completely proprietary and abandoning the goal of having good, stable and supported software.

[1] osmc/build.sh at master · osmc/osmc · GitHub
[2] https://cdn.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.14.29

1 Like


Thanks for your interest in Vero 4K.

Vero 4K currently ships with a 3.14.29 kernel. Obviously this is not really a 3.14.29 kernel, in the same way that Red Hat 2.6.32 kernels aren’t either. It’s much more modern.

  • V4L2 is backported to 4.4 (which is LTS)
  • The kernel is still actively maintained by the SoC maintainer; on a weekly basis
  • There are efforts for a 4.14 kernel by end of year
  • All CVEs are backported
  • Linaro are still maintaining this kernel
  • OSMC provides a SW maintenance guarantee for Vero 4K until at least 2022.

As such, there isn’t much concern from current customers when everything works and we keep everything working (security updates too).

There’s a 4.9 branch here but not quite there yet (headless).

GPUs and VPUs are closed.

Unfortunately not. On Pi, all video decoding is done in a black box as well.

If you need a new feature from a current kernel, we will do our best to backport it in the interim, as we have done with RC; DVB; and Docker support.

We won’t move off 3.14 until Q1-18 at the earliest and a lot of testing. But we won’t be on 3.14 for long in the context of the device’s lifetime.

Let me know if you have any concerns.


1 Like

Thanks Sam, those are very good points.

It’s great that you have 4.14 on the roadmap. 4.14 is also planned to be a LTS kernel, so that really makes sense. Also good to hear that Linaro and SoC maintainer are still on this.

Its just that it sounds like a huge amount of work to keep this old kernel updated and running, with a lot of work done by the SoC maintainer and probably even more by you personally.

It’s hard to maintain and you are relying on Linaro and the SoC maintainers. While with platforms like the Pi, the upstream kernel support is now very good, along with a huge amount of open source projects already using the platform. That means the platform doesn’t suddenly die due to a corporate decision somewhere, you benefit from other peoples bugfixes and you mostly don’t even have to take care of backports.

I don’t have a feature in mind that I need right now specifically, this is more about me being uncomfortable overall with those kind of vendor/SoC frankenstein kernels. I understand that this is standard practice in the embedded world though.

The upgrade to 4.14 is a good thing and it shows that the board is not abandoned, but will the SoC vendor do the same thing again with a new kernel in 2020/2021 when the board is not “sexy” anymore? Most likely not. Is the SoC vendor actively upstreaming changes as well, or is the only goal to provide a working kernel?

Its true - OSMC guarantees SW maintenance until 2022. It’s just that the Pi platform is pretty much “open” for all intends and purposes, while this remains a board requiring custom vendor provided kernels.

1 Like

Feel free to donate to OSMC


Raspberry Pi does not currently use an upstream kernel in Raspbian; and there are no Raspberry Pi distributions that do. As such – I don’t think we’re in a significantly different boat than they are after seeing the latest efforts by AMLogic, Linaro and BayLibre.

With Raspberry Pi, you still have the same level of binary blobs (you can’t boot without one on a Pi) for video playback and good graphics support. That is changing on Pi, but it takes some time. The same applies for Vero 4K: in time, things are becoming more open.

Yes – there are ongoing upstreaming efforts. You can boot a vanilla kernel headless (4.11 or later) with OSMC.

In 2022, we realistically will sunset support for Vero 4K. That doesn’t mean it will stop working however. Userland will also still be maintainable trivially if people are still interested.

New LTS kernels will be supported for six years upstream, so when 4.14 drops we will see support until 2023. We are one of the SoC vendor’s largest customers in 2017; so we have some sway.

Original Pi devices may still be supported – but the Vero 4K will likely be more useful in 2022 because of its original feature set. With that said, I don’t think either device will be used much by then.

If you need an LTS guarantee beyond 2022, I’d recommend finding another device. I’m not quite sure where you’d find such a board, with such a support commitment and such a feature set however.


Ok, great.

No, I’m not looking for LTS guarantees. I’m looking for a device that has a healthy ecosystem around it, driven by community efforts (like raspbian). Seems like the S905X may become such a device one day. It’s clear to me now that it’s just to early in the S905X lifecycle to make a direct comparison with the Pi’s.

Thanks for clarifying, I really appreciate this.

FWIW, my Google phone runs Android 8.1.0 and uses the Linux 3.10.79 kernel.

With OSMC you have apt (Debian), which will give you a vast and expansible userland
You can also run any other Linux distributions, and the bootloader is open source.

Further – most Raspbian packages will run without any tinkering on Vero 4K. But OSMC is based on upstream Debian (which will be still maintained long after Vero 4K)

Let us know what you need from us, and we can do it for you.
Currently, we only guarantee what we sell: a good device, with five years of support.

If you have specific requirements or doubts, then let us know.

Ok, thanks Sam!

Heh… I have a gen 1 fire TV that’s going to be 4 years old next spring, I keep thinking I will find a reason to get rid of it, but I have a server than can transcode x265->x264 in decent enough quality, and Amazon keeps updating the software so the UI is current, it’s plenty fast for the formats it handles, and it does fine with Netflix, and all the streaming apps…

The OSMC is my videophile box, but everyone else is still happy with the Fire for watching Netflix and whatnot.

Given that there’s no obvious new format the horizon that Vero 4K can’t play, and especially that while I’m sure 8K will be a thing someday, it’s silly for anything but humongous screens… I’d be surprised if we don’t see plenty of Vero 4K’s still being used in 4+ years in much the same capacity as my Fire TV is now…

Not that you have any obligation to support it, of course, but as long as it’s useful plenty of people will probably still use it!

When support ends, things stay working, they’re just not maintained. We still have thousands of Apple TV users (2007 device) that enjoy the device and use it with OSMC daily.

Hopefully our commitment to AppleTV is a sign that when we support hardware and that when we do, we support it for a long, long time, and take things seriously.


Any information about the new kernel? I am interested in testing it on Vero4k, I found one behaviour change in CEC handling from Raspberry Pi 2 and I would like to test something newer to check if the behaviour is fixed there. Otherwise I will report it as a separate issue. Thanks.


What issue are you experiencing with CEC?

The issue is unlikely to be in the kernel, but rather in libCEC, and a newer kernel would not fix any issues.

I’d suggest starting a new thread with some logs and a description of the isue.

Efforts are still underway on a mainline kernel.