We are increasingly hearing about people developing on older devices, like the NXP i.MX6, facing issues with the provided Linux-based software being stuck on old versions or having been abandoned by the vendor. If you are in that position, the good news is that there are options open to you and we've supported clients through this already, for example in the agricultural and medical fields. But first it's important that we provide some context.

Some products have a long life cycle. Unlike our mobile phones, which are supported for a few years, the expectation for devices installed as part of our infrastructure and other similar settings is that they are expected to function for decades. With these and other devices increasingly being connected and exposed directly or indirectly to the internet, security is a crucial consideration that must be actively maintained.

Many of these devices have been built running Linux, and we see this continuing today, due to its availability and flexibility. In order to support their customers, many silicon vendors provide versions of Linux that have been specifically tailored to their offerings. These versions of Linux are typically referred to as "board support packages" (BSPs).

Board support packages have allowed vendors to rapidly provide support for their latest devices and Original Equipment Manufacturers (OEMs) have been able to quickly develop products using them, however the result has been to place the silicon vendor in the path between the open source projects being used and the OEM. This requires the vendor to expend effort for any new versions or security updates of these open source projects to reach the OEMs.

Many of the components in these BSPs, such as the Linux kernel, continue to be developed at a rapid pace. For example, with the kernel (a critical component to providing a lot of the device support), new releases are typically made every few months. Each of these releases forms the start of a stable kernel release, which is supported until the next release plus 3 months. It is typical to see a "Long term support (LTS)" kernel release being declared each year, which is supported for at least 2 years. Silicon vendors will typically track the LTS kernel to provide security updates from time to time, as part of their BSPs. This may include jumps to newer LTS kernels, should the relevant device be supported in a newer BSP release. The cadence of releases and support offered for other components in the Linux ecosystem can substantially differ from the kernel's. Dependencies between the various components, their differing release cadences, and approaches to security updates (for example, whether they have stable trees or if all fixes are applied to the development branch) may present additional challenges.

Shifting bespoke support that's "out-of-tree" (code that is not part of the open source project's main development tree) to newer versions is a time consuming task. It can often lead to difficult issues where changes in the upstream (components' main development tree) over time conflict with or significantly change how the bespoke code added by a vendor needs to be integrated.

Like any other product, those produced by silicon vendors have a life cycle, with the length of time that a given product is on the market being a feature of their offering. Some silicon vendors may commit to offering the product for as long as 15 years or even longer, under certain circumstances. However a commitment to providing the physical silicon for a defined period doesn't necessarily mean they are going to be providing software support over a similar time frame. The vendors' focus will be drawn towards newer products. A result of this decline in focus can be a desire on the part of the silicon vendor to reduce the time and effort spent providing updates for older products.

Whilst the upstream kernel and other components do gain support for devices over time, for many this may be long after the initial device release. The support also may not be as feature-rich as the support offered by the vendor's BSP and may be implemented in a different way than that which the vendor ships in their BSP. This can make it difficult for OEMs to switch away from the vendors' BSPs even if support is available.

At Collabora we are passionate advocates of open source. Our knowledgeable team of engineers is experienced in resolving these issues, having worked with many clients to implement missing support, rectify feature gaps, and help clients adapt to differing implementations. This has enabled our clients to confidently migrate away from vendor-provided BSPs to support provided directly by upstream projects.

As highlighted by Arnd Bergmann in his talk at Open Source Summit Europe last month, whilst the number of ARMv7 boards such as those powered by an i.MX6 is reducing significantly over time, boards are still being added, especially those based on the i.MX6. Support for these platforms is expected to be added in the upstream kernel for quite a while yet.

Once support has found its way into the upstream projects, the effort required to migrate to newer versions is dramatically reduced as there are no (or fewer) out-of-tree patches to move to a newer release. Interfaces and functionality of components can and do change over time, but this typically happens slowly, with projects like the kernel providing promises not to break users of interfaces. Moving to an upstream kernel can have a knock-on effect further up the software stack, allowing devices to operate with unpatched upstream media frameworks such as Mesa, GStreamer, and PipeWire. This allows our clients to move to new versions of these components much more easily and take advantage of improved hardware support and new features. This enables them to enhance their products, as well as benefit from any security fixes provided by the upstream authors without time-consuming backporting of fixes or waiting for vendors to provide a new release.

Additionally the use of these open source frameworks enables more of the software stack to be shared between devices, maybe with SoCs from different vendors, targeting differing use cases or generations of a device, further reducing the development and maintenance effort required. A move away from vendor layers, for those using build systems such as Yocto, can also help remove some of the complexity of managing those systems.

We'd love to help everyone start off with a fully open, vendor BSP free software stack to build on from day one (as we've helped clients in the construction tools, sports technology, and digital inclusion fields achieve), however we appreciate that many may need to use vendor BSPs initially to get to market on time, within budget, or may have not been aware that other approaches were available. The good news is that it's never too late to switch. If you are currently stuck with a vendor BSP and would like to evaluate what modern upstream support has to offer, please get in contact and we can help you find a path forward.