BSP Tracker / BSP Status / STMicroelectronics
ST STM32MP2 (STM32MP257)
Mostly fine for CPU, peripherals and video decode. Not if the NPU is why you chose the part: the Neural-ART accelerator has no mainline driver, so an AI product is locked to OpenSTLinux and X-LINUX-AI. Note the SoC landed upstream (v6.5) BEFORE the vendor branch it ships on (6.6).
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 |
|---|---|---|---|
| VPU decode | Hantro (VeriSilicon) | upstream | CONFIG_VIDEO_HANTRO_STM32MP25 + stm32mp25_vpu_hw.c — decode driver is in mainline. |
| VPU encode | Hantro H1 (VeriSilicon) | upstream | stm32mp25_venc_variant in drivers/media/platform/verisilicon registers HANTRO_JPEG_ENCODER only (JPEG / M-JPEG). There is no H.264 or HEVC video encode upstream, so a mainline video-recording product is not covered. |
| NPU | ST Neural-ART (1.35 TOPS) | missing | No ST driver in drivers/accel. AI is X-LINUX-AI toolchain only. |
| GPU | VeriSilicon 3D | unverified | |
| ISP | DCMIPP | unverified |
Vendor BSP
Repository. https://github.com/STMicroelectronics/linux
Newest branch that actually exists. v6.6-stm32mp, tracking Linux 6.6. Last commit 2026-06-01.
Cadence. There is NO separate STM32MP2 branch and NO 6.12 branch. v6.6-stm32mp is the newest branch that exists, full stop.
Silicon longevity
The vendor publishes no commitment. Same as STM32MP1: no per-part table. A '10 years / 2029' figure surfaced during research but was not supported by any text on ST's page, and was discarded.
Yocto
Layer. meta-st-stm32mp. A branch for the current LTS exists: wrynose_v26.02.18.
master is a 2019 stub. Never build from it.
Hardware you can buy
Evaluate on. STM32MP257F-DK, STM32MP257F-EV1
Production modules.
- phyFLEX-STM32MP25x FPSC — PHYTEC
- DHCOS STM32MP2x — DH electronics
- MYC-LD25X — MYIR
What to do about it
ST STM32MP2 (STM32MP257): upstream fixes stop December 2027. That leaves 16 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.
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