BSP Tracker / BSP Status / Renesas
Renesas RZ/G2L (R9A07G044)
Renesas upstreams aggressively and its BSP is CIP-based — mainline plus a small delta on a super-long-term-support kernel. GPU and camera are upstream; the H.264 codec is not. The real reason to stay on the vendor tree is the ten-year maintained kernel, which mainline does not give you.
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 |
|---|---|---|---|
| GPU | Mali-G31 (Bifrost) | upstream | renesas,r9a07g044-mali; panfrost. |
| VPU decode | H.264 codec unit | missing | Renesas lists Image Codec = H.264 enc/dec on the part, so the block exists on silicon. No decoder driver in drivers/media/platform/renesas at v6.18, and neither the Hantro nor the Chips&Media wave5 driver claims Renesas. Decode is Verified-Linux-Package only. |
| VPU encode | H.264 codec unit | missing | Same H.264 codec unit as decode. No encoder driver in drivers/media/platform/renesas at v6.18; VIDEO_HANTRO depends on MXC/ROCKCHIP/AT91/SUNXI/STM32 only, and wave5 depends on ARCH_K3. Encode is Verified-Linux-Package only. |
| NPU | none (DRP-AI is on RZ/V2L) | n/a | Renesas lists NPU = No for every R9A07G044 variant; the DRP-AI accelerator is on the pin-compatible RZ/V2L (R9A07G054). RZ/G2L has Mali-G31 plus an H.264 codec and no AI block. |
| ISP | CRU + MIPI CSI-2 | upstream | renesas,rzg2l-cru; drivers/media/platform/renesas. |
Vendor BSP
Repository. https://github.com/renesas-rz/rz_linux-cip
Newest branch that actually exists. rz-6.12-cip14, tracking Linux 6.12. Last commit 2026-05-25.
Cadence. Built on CIP SLTS kernels — the point of which is a maintained kernel for a decade, which mainline does not offer. Branches: 5.10-cip54, 6.1-cip43, 6.12-cip14, each with a PREEMPT_RT variant.
Silicon longevity
Committed until 2038. The product page carries a Product Longevity Program badge for 2038. The wording is intent rather than guarantee: Renesas 'strives to maintain supply' for the duration of programme participation.
Yocto
Layer. meta-renesas. No branch for the current Yocto LTS.
No wrynose branch. Worse, much of the shipped Verified Linux Package tooling still sits on dunfell branches — Yocto 3.1. If your build policy requires the current LTS, RZ/G2L has no layer branch for it.
Hardware you can buy
Evaluate on. RZ/G2L Evaluation Board Kit (SMARC), MYIR MYD-YG2LX
Production modules.
- MYC-YG2LX CPU module — MYIR
- TRIA SM2S-G2L (SMARC 2.1.1) — Tria Technologies
- SOM-G2L-OSM — Geniatech
Notes
The best boring-industrial profile here: a real 2038 longevity badge, a CIP super-long-term kernel, upstream-first, three independent SoM sources. Its weakness is Yocto and the closed video codec.
What to do about it
Renesas RZ/G2L (R9A07G044): upstream fixes stop December 2028. That leaves 28 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