Home › BSP Tracker
Your vendor BSP is pinned to a kernel. When do its security fixes stop?
Answering that needs two facts that are kept in different places: which kernel a vendor branch actually tracks, and the date that kernel stops receiving upstream fixes. We put the two together for 17 SoCs and the modules built on them, and keep the result current.
Least time remaining
The three SoCs with the fewest months of upstream fixes remaining.
- NVIDIA Jetson Orin (Tegra234)Linux 6.8 · not an LTS · already unsupported
- Allwinner T507 / T527Linux 5.15 · 5 months left
- Rockchip RK3588 / RK3588SLinux 6.1 · 17 months left
What a BSP tracker is
Most products do not boot a kernel taken straight from kernel.org. They boot the BSP — the board support package — the silicon vendor’s own kernel: a fork of some upstream release, plus the drivers for their GPU, their camera pipeline, their NPU. Mainline-only products exist, and on a well-supported SoC that is the right place to end up; it is a decision teams make deliberately, and this page is partly about what it costs.
That fork is pinned to one kernel version. NXP’s lf-6.18.y is Linux 6.18. Rockchip’s develop-6.1 is Linux 6.1. And every upstream kernel has a date after which it stops receiving security fixes.
Put those two facts together and you get a date: the day the kernel in your product stops receiving security fixes, and patching it becomes your team’s job. This page keeps that date current for 17 SoCs, and records what stops working if you move off the vendor BSP.
If you already run mainline, the same two columns still apply: the LTS you picked has an end date, and the blocks upstream does not yet drive on your SoC are listed here as well.
You are choosing silicon for a product
Before the schematic is frozen. A chip chosen in 2026 whose BSP is based on a kernel that reaches end of life in 2027 carries a maintenance cost that is rarely in the budget, and by then the hardware decision can no longer be changed.
Your BSP kernel is heading for end of life
You have three options: backport the fixes yourself, move to the vendor’s newer BSP, or move to mainline. Each record shows which of them are available to you, and exactly which blocks stop working if you choose mainline.
Security asks who patches this kernel
When the next kernel CVE is published, who provides the fix? If the BSP is pinned to a series that is not a longterm kernel, upstream provides nothing and the answer is your team. It is better to know that before the question is asked.
Procurement asks if you can still buy it in 2032
Only 4 of 17 vendors here publish a commitment to keep selling the part. A ten-year figure usually comes from the module maker, and it covers their module, not the chip on it.
How they were chosen. The parts engineering teams are designing in today: silicon in current production, from the small MPU class up to edge-AI, together with the 41 production modules available from 20 module makers built on them. This is not a catalogue of every part made; it is the set that appears in real product decisions.
What it tracks, for every SoC
Seven fields per chip. Each one is read from a primary source and re-checked weekly, and any field we cannot confirm is published as unverified rather than filled in with a guess.
The vendor BSP branch
The newest branch that actually exists in the vendor’s git — not the one their documentation points at — and the kernel version it tracks.
The security cliff
The date that kernel stops receiving upstream fixes, and how many months that leaves you. Derived by joining the branch against kernel.org.
Mainline since
The first upstream release containing the SoC, proven by bracketing: the device tree must 404 at the previous tag and 200 at the stated one.
Mainline support, block by block
GPU, video decode, video encode, NPU, ISP. Each marked upstream, missing, vendor-only or unverified, so you know exactly what stops working if you move off the vendor BSP.
Silicon longevity
How long the vendor commits to selling you the part — taken from their own page. Where they publish nothing, the field says so.
The Yocto layer
What the layer declares in conf/layer.conf, and whether a branch for that release actually exists behind the claim.
Hardware you can buy
The eval board, and the production modules a real product would ship — because a dev board is not a product.
develop-6.1 → Linux 6.1. The repository also carries a develop-6.6 branch, but its last commit is ten months old: the newest branch is not the maintained one.v6.3, bracketed against the kernel tags.meta-rockchip · a branch for the current LTS exists.What the data says right now
Not opinions. Each of these falls out of the seven fields above. We re-check them every week against the sources they came from and keep the tables current, so as the data moves this section moves with it.
A flagship BSP is running a kernel upstream no longer supports
NVIDIA’s current Jetson Linux ships Linux 6.8. That is not a longterm series, so upstream stable support for it has already ended, which means NVIDIA backports every security fix in that BSP on its own. Mainline is not an alternative here: CUDA, TensorRT, the DLA and the camera stack are all proprietary.
Only 4 of 17 vendors will commit to selling you the part
NXP’s longevity table contains no i.MX rows at all. TI publishes a policy, not a commitment. Rockchip, Amlogic and Allwinner publish nothing. Every ten-year figure you have been quoted for those parts came from a module maker — who is committing for their module, not for the silicon.
See who commits, and who does not →The newest branch is not always the maintained one
Rockchip publishes a develop-6.6 branch, but its last commit is ten months old, while the repository default branch develop-6.1 is the tree actually being worked on. A team that reads branch names alone will pick the wrong kernel. We check the git refs, not the release notes.
Mainline support is better than expected on some SoCs, and worse on others
7 of 17 SoCs here can ship on mainline directly. The RK3588 GPU, video decode and NPU are all supported upstream, so moving that SoC to mainline improves its security rather than reducing it. On 2 others, the accelerator the chip was chosen for is supported only in the vendor tree. Each record lists exactly which blocks stop working.
See the per-block breakdown →Why you can trust a number on this page
Because none of it is asserted. We take every value from a primary source, we show you the source next to the claim, and we keep it current.
We read the refs, not the docs
A vendor’s documentation says which branch to use. We list what is actually in the repository, take the newest branch that genuinely exists, and record the date of its last commit.
We bracket every mainline claim
“Mainline since v5.7” means the SoC device tree returns 404 at v5.6 and 200 at v5.7 in the kernel tree. Both URLs are on the page. It is the same check a maintainer would do by hand.
When we cannot confirm it, we say so
A field marked unverified is a correct outcome, not a gap we forgot to fill. A missing row is better than a wrong one, and that is the whole reason this is worth checking.
What is inside
Four maintained tables. They join on the kernel version, which makes them more useful together than separately.
BSP Status
For each SoC: the kernel its vendor BSP pins, the date upstream fixes stop, whether mainline is an option, and exactly which blocks stop working if you move to it.
Kernel lifecycles
Every longterm series, its current patch level, and when the stable maintainers expect to stop supporting it. This is the table everything else joins against.
Yocto layers
What each vendor layer declares in conf/layer.conf, which release branches actually exist behind that claim, and when each layer last saw a commit.
Learning boards
The Raspberry Pi, the BeagleBone and the rest: superb to learn on, and not production hardware. Each one points at the SoC or module a real product would use instead.
What changed
Only real movement is listed. When nothing moved, nothing is listed — a page that manufactures activity is a page you stop trusting.
- kernelMainline moved to
7.2-rc3. No longterm series took a patch release since 2026-07-04, so no security cliff moved. - bspQualcomm QCS6490 (RB3 Gen 2)
qcom-HEAD moved to 2026-07-14.6.18.yqcom-is still stalled at 2026-03-11.6.19 - yoctoAllwinner T507 / T527
meta-sunximaster moved to 2026-07-13, with still no wrynose branch cut. - dataThe
meta-intelrow's last-commit date is corrected to 2026-06-10, read from the wrynose branch log.
- kernelStable releases rolled to
6.18.38,6.12.95,6.6.144,6.1.177,5.15.211and5.10.260. No EOL date moved, so no security cliff moved. - bspQualcomm QCS6490 (RB3 Gen 2)A
qcom-branch now exists, but its HEAD is 2026-03-11 and carries only FROMLIST patches.6.19qcom-is still the branch being fed, so the record stays there.6.18.y - bspRockchip RK3588 / RK3588S
develop-remains the live tree, HEAD 2025-12-26.6.1develop-has not moved since 2025-09-01.6.6 - yoctoTI AM335x (Sitara)
meta-tiwrynose ships am335x-evm.confand declaresLAYERSERIES_COMPAT= whinlatter wrynose. Current-LTS support is now confirmed rather than unverified. - yoctoNXP i.MX6ULL
meta-imxwrynose-6.18.20-2.0.0shipsimx6ull14x14evk.conf. Current-LTS support is now confirmed rather than unverified. - yoctoQualcomm QCS6490 (RB3 Gen 2)
meta-qcomwrynose last commit moved to 2026-07-11.
What happens when your BSP kernel reaches end of life
Someone has to backport the security fixes, move the product to a newer vendor kernel, or move it to mainline. All three are engineering work, not a procurement decision. We do this work with product teams, and we train teams to do it themselves.
Get the updates
An email when a kernel series reaches end of life, an SoC row changes, or a layer picks up a release branch. Nothing else.
RSS