Upstream-First BSP: Why Vendors Are Moving to Mainline

For most of the history of embedded Linux, a chip vendor’s upstream-first BSP was not something you expected. You received a vendor kernel, usually an older version with a large set of out-of-tree patches, and you built your product on that fork. In 2025 and 2026 that model started to change in public, with two of the largest players in the field moving deliberately toward mainline. This article looks at what upstream-first means in practice, why it is happening now, and what it changes for the day-to-day work of an embedded engineer. It is a view on where the field is going, backed by what the vendors have actually announced.

The old model: a BSP is a kernel fork

A traditional BSP is a snapshot of the Linux kernel, chosen by the silicon vendor, with board and SoC support added as patches on top. That support — clock trees, pin controllers, camera and display pipelines, power management, accelerators — often never reaches the mainline kernel, or reaches it years later. The result is a fork that lags upstream and that the product team must carry for the life of the device. The Android project has described this fragmentation reaching as much as half of the kernel code on a shipping device, once vendor and original-equipment-manufacturer changes are counted, most of it out-of-tree.

Carrying a fork has a cost that grows over time. Every security fix from upstream must be backported by hand. Every kernel uplift means forward-porting the whole patch set to a newer base and re-testing. When the product lives for eight or ten years, that cost is paid again and again, and it is paid by whoever owns the board, not by the chip vendor.

What upstream-first BSP means

An upstream-first model reverses the default. The SoC and board support is written to be accepted into the mainline kernel first, and the vendor’s product BSP is built by tracking mainline and applying a small, well-defined set of overlays for anything not yet upstream. Qualcomm has stated this directly for its Dragonwing IoT line: with Qualcomm Linux 2.0, announced in June 2026, it describes “an upstream-first model with a BSP that tracks mainline to minimize friction”, using a single system image and an overlay-based architecture to keep customizations separate from the base. The stack supports both the mainline kernel and the current long-term-support kernel, which is Linux 6.18.

This was not a sudden change. In September 2025, one day after Qualcomm announced the Snapdragon 8 Elite Gen 5, it posted the initial mainline enablement patches for the platform to the upstream kernel maintainers — a departure from the long pattern where Snapdragon Linux support arrived months or years late, if at all. Much of the groundwork for booting mainline Linux on Qualcomm hardware has been done over years by Linaro, working with the upstream community rather than inside a private tree.

Android’s GKI pushed in the same direction

Google reached the same conclusion earlier through the Generic Kernel Image (GKI) project. Rather than let every vendor and OEM ship a different kernel, GKI unifies the core kernel and moves SoC and board support out of that core into loadable vendor modules. It also defines a stable Kernel Module Interface (KMI), so the generic kernel and the vendor modules can be updated independently. The stated goal is to reduce fragmentation and to let security patches reach devices faster, because the core kernel is shared rather than re-forked per device.

GKI and Qualcomm’s approach are not identical — GKI standardizes a binary interface for modules on Android, while Qualcomm Linux 2.0 is a wider embedded and IoT effort — but they point the same way. Both treat a large downstream fork as a liability to be reduced, not a normal cost of doing business.

Why this is happening now

Two pressures make the fork model more expensive than it used to be. The first is the shorter kernel support window. As covered in our note on planning embedded products around kernel LTS support, the default support period for a new long-term-support kernel is now two years rather than six. A shorter window means more frequent rebases, and rebasing a large private patch set is exactly the work that upstream-first is meant to avoid.

The second pressure is regulation and security. Rules such as the EU Cyber Resilience Act expect device makers to deliver security updates across a product’s supported life. A fork that is far from mainline makes that promise harder to keep, because each upstream fix has to be located, backported, and tested by the product team. Code that is already in mainline receives stable backports for the life of the branch, which lowers the ongoing cost of staying secure.

What it changes for embedded engineers

If the BSP becomes “mainline plus an overlay,” the skills that matter shift with it. Applying a vendor tarball and moving on is no longer the whole job. The valuable work moves toward being able to operate at the mainline boundary:

• Reading and writing device tree. When board support is upstream, describing hardware in device tree and matching it to drivers through the compatible property is the main interface you touch.
• Getting code accepted upstream. Preparing a clean patch series, writing a binding, and responding to maintainer review become commercial skills, not just community contributions.
• Understanding the module boundary. On GKI-style stacks, knowing what belongs in a loadable vendor module versus the shared core kernel is part of the design, because of the stable module interface.
• Forward-porting deliberately. Keeping an overlay small and rebasing it cleanly onto a new kernel is a different discipline from maintaining a permanent fork.

A concrete first check is to find out how far your platform already is from mainline. You can look for your SoC in the upstream device tree source directly:

raghu@techveda.org:~$ ls arch/arm64/boot/dts/qcom/ | grep -i sm8650

If your SoC’s .dtsi and a matching board .dts are present in the mainline tree (the example above is the Snapdragon 8 Gen 3, which is supported upstream), your platform is close to mainline and your overlay can be small. If the files exist only inside a vendor fork, you are still carrying out-of-tree code, and that gap is the work an upstream-first plan sets out to close. Learning to move a board from a vendor fork toward mainline is part of the board bring-up and integration work covered in our Embedded Linux training.

What it does not change

It is worth being precise about the limits of this shift. Upstream-first does not mean fully open. Qualcomm Linux 2.0 is described as upstream-aligned rather than a standalone open distribution, and it still pairs upstream components with closed binaries for parts such as the AI accelerator, camera, graphics, and hypervisor. Board bring-up is still difficult work, and the hardest pieces — multimedia, imaging, and accelerators — are often the last to reach mainline, if they arrive at all. A same-day upstream posting is also a starting point, not a finished port; the real test is whether a vendor sustains the effort across several product generations. The direction is clear, but the destination is “closer to mainline,” not “entirely in mainline.”

Key takeaways

• Several silicon vendors are moving from a fork-based BSP to an upstream-first BSP that tracks the mainline kernel and keeps additions as small overlays.
• Qualcomm Linux 2.0 (announced June 2026) states an upstream-first model with a BSP that tracks mainline; Qualcomm posted initial mainline patches for the Snapdragon 8 Elite Gen 5 one day after its 2025 announcement.
• Google’s Generic Kernel Image reached the same goal earlier by unifying the core kernel, moving board support into loadable vendor modules, and defining a stable module interface.
• The change is driven by economics: shorter LTS windows and mandated security updates make a large downstream fork more expensive to carry.
• For engineers, value moves toward device tree, upstream bindings, patch submission, and disciplined forward-porting — not just applying a vendor tarball.
• It does not mean fully open: closed binaries for accelerators, camera, and graphics remain, and bring-up is still hard work.

Frequently asked questions

What is an upstream-first BSP?
It is a board support package built by tracking the mainline Linux kernel and applying a small set of overlays for anything not yet upstream, rather than shipping an older kernel with a large private patch set. The SoC and board support is written to be accepted into mainline first.

How is this different from a traditional vendor BSP?
A traditional BSP is a kernel fork: an older base with board support added as out-of-tree patches that the product team must backport and forward-port for the life of the device. An upstream-first BSP keeps most of that support in mainline, so the team carries a much smaller overlay and receives upstream stable fixes directly.

Why are vendors moving to upstream-first now?
The default kernel LTS support window dropped from six years to two, which means more frequent rebases, and regulations such as the EU Cyber Resilience Act require security updates across a product’s life. Both make a large downstream fork more expensive, so keeping code in mainline lowers the ongoing cost.

Does upstream-first mean the whole stack is open source?
No. Qualcomm Linux 2.0, for example, is upstream-aligned but still ships closed binaries for parts such as the AI accelerator, camera, graphics, and hypervisor. Upstream-first reduces the size of the downstream fork; it does not remove every proprietary component.

Further reading

• Qualcomm promises a major reset with upstream-first, Qualcomm Linux 2.0 for Dragonwing IoT platforms — CNX Software, June 2026.
• Generic Kernel Image (GKI) project — Android Open Source Project.
• Upstream Linux support for the Qualcomm Snapdragon 8 Gen 3 Mobile Platform — Linaro.
• The Shorter Kernel LTS Support Window: What It Means for Embedded Products — TECH VEDA.
• Active kernel releases and projected end-of-life dates — kernel.org.