BSP Tracker / BSP Status / Microchip
Microchip SAMA7G5 (SAMA7G54)
Microchip upstreams first and there is no GPU, VPU or NPU to lose. The camera path is upstream. A product can ship on mainline; the BSP mainly buys validated defconfigs and the at91bootstrap and OP-TEE integration.
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 | none | n/a | LCD controller only; no 3D GPU. |
| VPU | none | n/a | No hardware video codec. |
| NPU | none | n/a | No NPU. |
| ISP | XISC + CSI2DC | upstream | microchip,xisc binding; drivers/media/platform/microchip. |
Vendor BSP
Repository. https://github.com/linux4microchip/linux
Newest branch that actually exists. linux-6.18-mchp, tracking Linux 6.18. Last commit 2026-06-16.
Cadence. A clean branch per kernel: 5.10, 5.15, 6.1, 6.6, 6.12, 6.18, each -mchp. Microchip upstreams first, so these branches are mainline plus a small delta.
Silicon longevity
The vendor publishes no commitment. No per-part commitment, despite the reputation. Microchip publishes a policy — it pledges not to discontinue products with recent business activity, if they can still be manufactured. The product page says only 'In Production'. Note the trap: AN4532 'Product Lifetime Estimation' is about silicon wear-out, not supply.
Yocto
Layer. meta-atmel. No branch for the current Yocto LTS.
No wrynose branch — the layer jumps kirkstone to scarthgap. So the Yocto layer is a full LTS behind, even though the kernel tree is on 6.18.
Hardware you can buy
Evaluate on. SAMA7G54-EK (EV21H18A)
Production modules.
- SAMA7G54 SOM (EA16Z43A, early access) — Microchip
- SAMA7G54D2G System-in-Package — Microchip
Notes
The only module is Microchip's own, and it is still pre-production. For volume, the realistic part is the SiP — a package, not a SoM.
What to do about it
Microchip SAMA7G5 (SAMA7G54): 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