BSP Tracker / BSP Status / NXP
NXP i.MX93
The strongest mainline story of the NXP parts. No 3D GPU and no VPU means there is almost nothing proprietary to lose, and the Ethos-U65 NPU now has an in-tree accel driver.
Mainline instead of the vendor BSP
Can you ship mainline instead, and what exactly do you lose if you do?
Mainline is shippable
| Block | IP | Upstream | Detail |
|---|---|---|---|
| NPU | Arm Ethos-U65 | upstream | CONFIG_DRM_ACCEL_ARM_ETHOSU (drivers/accel/ethosu). Userspace (Vela) maturity not assessed. |
| GPU | none (2D PXP only) | upstream | CONFIG_VIDEO_IMX_PXP. Nothing to lose. |
| VPU | none | n/a | No video codec block on this SoC. |
| Camera | MIPI CSI-2 + ISI | upstream | drivers/media/platform/nxp; no ISP block on this part. |
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. Same family-wide branch set as the rest of i.MX.
Silicon longevity
The vendor publishes no commitment. No i.MX93 row in NXP's longevity table.
Yocto
Layer. meta-imx. A branch for the current LTS exists: wrynose-6.18.20-2.0.0.
Hardware you can buy
Notes
Ethos-U65 as the i.MX93 NPU is vendor documentation; the Kconfig proves the driver exists, not the i.MX93 binding.
What to do about it
NXP i.MX93: 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 this SoC, so the migration is substantial work but not research. 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.
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