BSP Tracker / BSP Status / STMicroelectronics
ST STM32MP1 (STM32MP157)
The one SoC here where the vendor kernel is a convenience rather than a necessity. ST upstreams first and back-ports to its own tree. What you keep from ST is the boot chain (TF-A, OP-TEE), not secret drivers.
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 |
|---|---|---|---|
| GPU | Vivante GC400 | unverified | Expected to work via etnaviv; a GPU node in the mainline dtsi was not verified. |
| VPU | none | unverified | Believed to have no hardware codec IP; not confirmed against the reference manual. |
| Boot chain | TF-A + OP-TEE | vendor | Still required from OpenSTLinux regardless of kernel. |
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. Only 7 branches exist. One LTS rebase roughly every 18-24 months. A SINGLE branch serves both STM32MP1 and STM32MP2.
Silicon longevity
The vendor publishes no commitment. ST's longevity page states a 7-to-20-year range and does not enumerate STM32MP. The product page carries no longevity statement. The widely repeated '10 years' is not backed by a per-part table.
Yocto
Layer. meta-st-stm32mp. A branch for the current LTS exists: wrynose_v26.02.18.
The master branch is a STALE STUB — its only commit is from Feb 2019 ('Add README'). Never build from master. The Wrynose branch is named wrynose_v26.02.18, not wrynose.
Hardware you can buy
Evaluate on. STM32MP157F-DK2, STM32MP157C-EV1
Production modules.
- OSD32MP15x SiP — Octavo Systems
- SOM-SL STM32MP157 — Kontron
- STMP157-SOM-512 — Olimex
Notes
Neither Toradex nor Variscite build an STM32MP1 SoM.
What to do about it
ST STM32MP1 (STM32MP157): upstream fixes stop December 2027. That leaves 17 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