NXP i.MX8M Plus — Linux BSP, Mainline Support and EOL

Jump to a SoC

Security cliff

Upstream fixes for Linux 6.18 stop in December 2028 — 29 months from now.

The vendor BSP tracks Linux 6.18 on branch lf-6.18.y. After that date no fixes arrive from upstream, and maintaining this kernel becomes your job.

Mainline instead of the vendor BSP

Can you ship mainline instead, and what exactly do you lose if you do?

Mainline, with named losses

Block	IP	Upstream	Detail
GPU	Vivante GC7000UL	upstream	etnaviv; parity with the proprietary Vivante stack not assessed.
VPU decode	Hantro G1/G2	upstream	CONFIG_VIDEO_HANTRO_IMX8M
VPU encode	VC8000E/H1	missing	No encoder in drivers/media/platform/verisilicon.
ISP	VeriSilicon ISP8000	missing	Capture works via ISI, but there is no 3A/HDR pipeline upstream.
NPU	VeriSilicon VIP8000 (2.3 TOPS)	missing	No driver in drivers/accel. Mesa Teflon is a community path, not the vendor stack.

Mainline since v5.7, verified by bracketing the device tree against the kernel tags: proof 1 · proof 2

Vendor BSP

Repository. https://github.com/nxp-imx/linux-imx

Newest branch that actually exists. lf-6.18.y, tracking Linux 6.18. Last commit 2026-06-09.

Cadence. One lf-<LTS>.y branch per kernel LTS. lf-6.6.y and lf-6.12.y have had no commits since Nov 2025; only lf-6.18.y is active.

Silicon longevity

The vendor publishes no commitment. NXP's Active Longevity Products table contains no i.MX applications-processor rows. The 15-year figure appears only in marketing copy. Get it in writing from NXP.

Vendor source

Yocto

Layer. meta-imx. A branch for the current LTS exists: wrynose-6.18.20-2.0.0.

Hardware you can buy

Evaluate on. i.MX 8M Plus EVK

Production modules.

Verdin iMX8M Plus — Toradex
VAR-SOM-MX8M-PLUS — Variscite
phyCORE-i.MX 8M Plus — PHYTEC

Notes

Branch existence does not prove this SoC is still enabled on that branch.

What to do about it

NXP i.MX8M Plus: upstream fixes stop December 2028. That leaves 29 months. After that date the kernel this BSP is based on receives no further security fixes from upstream, and maintaining it becomes your team’s responsibility.

There are three options:

Backport the fixes yourself. Your team maintains a kernel that nobody else maintains: tracking each CVE, applying the patch to a tree that has diverged from upstream, and testing the result, for as long as the product ships.
Move to the vendor’s newer BSP. This gives you a few more years of upstream fixes, and it costs a second bring-up: a new kernel, your patches forward-ported, drivers re-validated, and the product re-tested.
Move to mainline. Mainline supports part of this SoC. The blocks marked above are the ones a migration has to solve or replace. It is the only option that does not have to be repeated when the next vendor kernel reaches end of life.

All three are engineering work, and all three are work we do: reading vendor kernel trees, checking what mainline actually supports, and moving products from one to the other. This page is built from the same work.

Embedded Linux engineering →Talk to us about your BSP

Get the updates

An email when a kernel series reaches end of life, a board row changes, or a layer picks up a release branch. Nothing else.

RSS