BSP Tracker / BSP Status / Texas Instruments
TI AM62x (AM625)
Arguably the best mainline-shippable SoC in this set. The GPU — the block that is normally proprietary — has a real upstream DRM driver with a TI-specific compatible string. What you give up by leaving the BSP is integration convenience, not silicon function.
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 | PowerVR AXE-1-16M | upstream | Binding img,powervr-rogue.yaml lists ti,am62-gpu -> img,img-axe-1-16m. In-tree Imagination DRM driver + Mesa. |
| VPU | none | n/a | No video codec accelerator on this SoC. |
| NPU | none | n/a | No AI accelerator on this SoC. |
Vendor BSP
Repository. https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel
Newest branch that actually exists. ti-linux-6.18.y, tracking Linux 6.18. Last commit 2026-07-09.
Cadence. Tracks each kernel LTS and keeps a matching PREEMPT_RT branch (ti-rt-linux-*), which is a real differentiator.
Silicon longevity
The vendor publishes no commitment. TI publishes a life-cycle policy ('typically 10 to 15 years'), not a dated per-part commitment. The '20-year' figure is marketing.
Yocto
Layer. meta-ti. A branch for the current LTS exists: wrynose.
Hardware you can buy
Evaluate on. SK-AM62B
Production modules.
- Verdin AM62 — Toradex
- phyCORE-AM62x — PHYTEC
- VAR-SOM-AM62 — Variscite
What to do about it
TI AM62x (AM625): 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