Your Automotive Linux BSP Moved to 6.12. Real Time Did Not.

If you are building a vehicle network processor image and you have assumed that real-time preemption arrives with the vendor tree, it is worth reading the branch names again. The public git history of the NXP S32 automotive Linux BSP records a change of shape that happened quietly, encoded in nothing more than the way branches are named. For roughly two years the BSP published its kernels in pairs, and every one of those branches ended in -rt. It no longer does. This matters to anyone specifying latency behaviour for a gateway, a telematics unit or a domain controller built on this silicon, because the difference between the two configurations is not a tuning detail. It is a different kernel.

What the automotive Linux BSP publishes today

Two repositories carry the public artefacts of this automotive Linux BSP. nxp-auto-linux/auto_yocto_bsp holds the repo manifests that assemble a build, and nxp-auto-linux/linux holds the kernel itself. The manifest repository is where release identity lives: it carries a tag per BSP release, and those tags are the only public dating you get. Read on 12 September 2026, the newest of them is bsp48.0, tagged 30 July 2026, followed a day later by s32n7_bsp3.0 on 31 July 2026. Before those sit s32n7_bsp2.0 (3 July 2026), s32n7_bsp1.0 (12 May 2026), bsp46.0_s32n7_0.9 (13 March 2026), bsp46.0 (26 November 2025) and bsp45.0 (3 October 2025).

The kernel repository names its branches with the release and the kernel version joined together, which turns the branch list into a version history you can read directly. You do not need to clone anything to see it.

raghu@techveda.org:~$ git ls-remote --heads https://github.com/nxp-auto-linux/linux | awk '{print $2}' | grep -E "bsp4[5-8]"
refs/heads/release/bsp45.0-5.15.179-rt
refs/heads/release/bsp45.0-6.6.87-rt
refs/heads/release/bsp45.0_cd1-6.6.85-rt
refs/heads/release/bsp45.0_cd2-6.6.87-rt
refs/heads/release/bsp46.0-6.12.19
refs/heads/release/bsp46.0-6.6.99-rt
refs/heads/release/bsp46.0_s32n7_0.9-6.12.19
refs/heads/release/bsp48.0-6.12.92

Two things stand out immediately. There is no bsp47.0 anywhere — filtering the branch list on that string returns nothing at all, so the public numbering steps from 46.0 to 48.0 with no explanation offered. And bsp48.0 has exactly one branch where every release before bsp46.0 had two. That single branch, release/bsp48.0-6.12.92, was last updated on 6 August 2026 and carries no -rt suffix.

This position was first checked in late August and checked again on 12 September 2026. Nothing had moved: no newer BSP tag, no new branch of any kind, and the same result from the branch search. The stability is part of the finding, because a gap that persists across six weeks is a different thing from a repository caught mid-release.

Why the branch names carried “-rt” at all

The suffix was never decoration. Until recently, real-time preemption on Linux was an out-of-tree patch series maintained against specific stable kernel versions. Applying it meant taking a large, invasive set of changes that reworked spinlocks into sleeping locks, forced interrupt handlers into threads by default, and rewrote enough of the locking and timer machinery that it could not simply be switched on and off. The series announced itself in the source tree with a file called localversion-rt, whose contents were appended to the kernel version string. On the branch release/bsp46.0-6.6.99-rt that file exists and contains -rt58, which tells you both that the patch series is applied and precisely which revision of it.

That structure forced a vendor into an awkward position. A BSP kernel is already a fork: it carries SoC enablement, drivers for blocks that are not upstream yet, device trees, and errata workarounds. Adding an out-of-tree real-time series on top means maintaining the union of two independently moving patch sets against a stable base that itself moves every week. Rebasing that union is real work, and it is work that has to be repeated on every stable point release. The cheapest way to manage it was to keep the real-time variant on its own branch, so the ordinary automotive Linux BSP could move without dragging the real-time integration behind it. That is exactly what the branch list shows for every release from bsp38.0 in September 2023 onwards.

What changed, and when

The shape of this automotive Linux BSP changed at a single, identifiable point. Here is the sequence, taken from the branch and tag dates read on 12 September 2026.

Before November 2025, every kernel the BSP shipped had the real-time series applied. From bsp46.0 onward, the newer of the two kernels does not. And the 5.15 line, which had been present since before this history begins, disappears at the same moment: bsp45.0 in October 2025 is the last release to carry it.

The version at which this happens is not a coincidence. Linux 6.12, released 17 November 2024, is the release in which the real-time patch series was finally merged into mainline after roughly two decades of out-of-tree maintenance. The last blocker was the rewrite of printk(), and with that merged, building a kernel with the real-time configuration enabled became possible without any patch series at all. The BSP branch that first reaches 6.12 is release/bsp46.0-6.12.19, tagged three weeks after the vendor’s previous release. The -rt suffix vanishes on that branch and never returns.

Available upstream is not the same as enabled in your image

This is where the reasoning has to slow down, because the obvious conclusion is the wrong one. It would be easy to read “real time is upstream in 6.12” and infer that a 6.12 BSP therefore gives you a real-time kernel. It does not follow. Merging the series upstream removed the need for a separate branch. It did not decide what the shipped configuration selects.

You can check that directly. Clone the branch shallowly and look at two files.

raghu@techveda.org:~$ git clone --depth 1 -b release/bsp48.0-6.12.92 https://github.com/nxp-auto-linux/linux s32-6.12
raghu@techveda.org:~$ ls s32-6.12/localversion-rt
ls: cannot access 's32-6.12/localversion-rt': No such file or directory
raghu@techveda.org:~$ grep -E "^CONFIG_PREEMPT" s32-6.12/arch/arm64/configs/s32cc_defconfig
CONFIG_PREEMPT=y

The missing localversion-rt confirms there is no out-of-tree series applied, which is expected on a 6.12 base. The defconfig line is the substantive finding. CONFIG_PREEMPT=y selects the low-latency preemption model, the one that allows the kernel to be preempted at most points in kernel code but leaves spinlocks non-preemptible and leaves most interrupt handlers running in hard interrupt context. CONFIG_PREEMPT_RT, which is the symbol that would give you the real-time behaviour, is absent. So is any configuration fragment that might switch it on: the arch/arm64/configs directory on that branch contains defconfig, hardening.config, s32cc_defconfig, s32cc_emu_defconfig, s32cc_emu_mmc_delta_defconfig, s32n7_defconfig and virt.config, and nothing whose name suggests real-time.

The same defconfig sets CONFIG_IKCONFIG_PROC=y, which means a running board will expose its own configuration and you can settle the question on the target rather than reasoning from the source tree.

root@s32g399aevb3:~# zcat /proc/config.gz | grep -E "^CONFIG_PREEMPT_RT|^CONFIG_PREEMPT="
CONFIG_PREEMPT=y

One line back, and it is the wrong one if your requirement was bounded worst-case latency. This is a check worth running on any board before a latency budget is written down, not after.

The maintenance mismatch nobody advertises

There is a second consequence, and it is about lifetime rather than latency. According to the kernel.org longterm table read on 12 September 2026, Linux 6.12 was released on 17 November 2024 with a projected end of life of December 2028. Linux 6.6, released 29 October 2023, is projected to end in December 2027. Linux 5.15, the line this automotive Linux BSP dropped after October 2025, ends in December 2026 — about four months from now.

Line those up against the branch list and the position is clear. If you want the real-time behaviour and you take the only branch in this tree that has the series applied, you are choosing 6.6, and you are choosing a kernel whose upstream maintenance stops a year earlier than the 6.12 branch sitting next to it. If you want the longer-lived base, you take 6.12 and you inherit a configuration that is not real-time, which you would then have to change and validate yourself. The tree does not offer a branch that gives you both, and no public document explains how the vendor intends that gap to be closed. For a product that has to be maintained for a decade, that is a choice worth making deliberately rather than inheriting from whichever automotive Linux BSP branch happened to be checked out first.

That is a familiar shape of problem, and it is worth being systematic about it rather than discovering it late. The question of whether the kernel under your product still has upstream maintenance behind it, and how to establish that from artefacts rather than from a datasheet, is covered separately in SoC Kernel Support: How to Tell If Yours Has Already Lapsed.

How to check this on your own BSP

Nothing above is specific to one vendor. The method transfers to any automotive Linux BSP whose kernel is published in a git repository, and it takes a few minutes.

Start with the branch names, because vendors encode more in them than they document. A branch named after both a release and a kernel version tells you the base without cloning. Then check for localversion-rt: its presence means an out-of-tree series is applied and its contents identify the revision. On a base of 6.12 or later, its absence tells you nothing on its own, because the series no longer needs to be out of tree — so go to the configuration next. Grep the vendor defconfig for the preemption model. Then list the configs directory to see whether an alternative fragment is offered. Finally, if you have a board, read /proc/config.gz and trust that over anything else, because it is the only source that describes the kernel actually running.

One more line in that defconfig is worth reading before you plan any measurement, because it decides whether you can measure at all. The s32cc_defconfig on release/bsp48.0-6.12.92 contains # CONFIG_FTRACE is not set and # CONFIG_SCHED_DEBUG is not set. Ftrace is the machinery behind the kernel-side latency tracers, so a kernel built from this defconfig as delivered gives you no wakeup_rt tracer, no irqsoff or preemptoff tracer, and no scheduler debug output. cyclictest will still run and still report numbers, because it measures from user space, but when those numbers are worse than the budget there is nothing in the kernel to tell you which path caused it.

The order of work that follows from this is worth stating plainly. Establish the preemption model from the defconfig first, then check whether the same defconfig gives you the instrumentation to verify it, and expect to turn tracing on and rebuild before the first measurement rather than after a disappointing one. A vendor default configuration is tuned for a shipping image, where tracing costs memory and some throughput; it is not tuned for the bring-up work of deciding whether the preemption model it selects is good enough for your deadlines.

The build side of the automotive Linux BSP is ordinary Yocto, which means the configuration you end up with can also be changed by layer metadata rather than by the defconfig alone. The manifest repository offers several manifests — default.xml, plus adas.xml which adds the meta-adas layer and aa-integration.xml which adds Adaptive AUTOSAR integration — and the build is driven through nxp-setup-alb.sh with a machine name such as s32g399aevb3 or s32r45evb. If your image differs from what the defconfig implies, the meta-alb layer is where to look next.

What this evidence does not establish

The public repository is not the whole product, and it would be wrong to read the automotive Linux BSP that way. The README itself refers to internal Bitbucket manifests that are not mirrored publicly, so a real-time deliverable could exist through NXP’s own release channels without leaving a trace on GitHub. Nothing here should be read as a statement that real-time support has been withdrawn. What can be said is narrower and firmer: as of 12 September 2026 the public tree publishes no 6.12 branch with the real-time series applied, and the 6.12 defconfig it does publish selects CONFIG_PREEMPT.

Several things were checked and not resolved. NXP’s own release notes for BSP 48.0 sit behind a login and were not read, so no BSP release date beyond the git tag dates is asserted. The meta-alb layer’s recipes were not examined, so whether the Yocto build applies a configuration fragment on top of the defconfig is unknown. The s32n7 branches, which target a different part of the family, were read only for their names and versions. And there is no public statement anywhere that was found explaining the missing bsp47.0, so the gap is reported as observed and not interpreted.

Finally, this is one vendor. Whether Renesas, TI or Qualcomm have made the same transition at the same kernel boundary was not checked this week, and it would be a mistake to generalise from a single tree. The 6.12 boundary is common to everyone, since it is an upstream event, but each vendor’s response to it is theirs.

Key takeaways

• The NXP S32 automotive Linux BSP published paired kernel branches with the real-time series applied from bsp38.0 (September 2023) through bsp45.0 (October 2025).
• Reading branch names, localversion-rt and the vendor defconfig is enough to establish the preemption model of any automotive Linux BSP published in git.
• From bsp46.0 (26 November 2025) the newer kernel is 6.12 and carries no real-time series; by bsp48.0 (30 July 2026) only the 6.12 branch remains.
• The pivot lands on 6.12 because that is the release in which the real-time patch series was merged into mainline, removing the reason for a separate branch.
• Upstream availability did not change the shipped configuration. s32cc_defconfig on the 6.12 branch selects CONFIG_PREEMPT, not CONFIG_PREEMPT_RT.
• The same defconfig sets # CONFIG_FTRACE is not set, so the shipped configuration also gives you no kernel-side way to measure the latency it produces.
• The only branch with the real-time series applied is on 6.6, which kernel.org projects to end in December 2027; the 6.12 line runs to December 2028.
• Verify the preemption model from /proc/config.gz on the target before committing to a latency figure.

Frequently asked questions

Does a Linux 6.12 BSP give me a real-time kernel?

Not by itself. Linux 6.12 is the release in which the real-time patch series was merged into mainline, so the capability is present in the source tree. Whether it is active depends on the configuration, and on this BSP the shipped s32cc_defconfig selects CONFIG_PREEMPT rather than CONFIG_PREEMPT_RT.

What does the localversion-rt file tell me?

Its presence means the out-of-tree real-time patch series has been applied to that tree, and its contents name the revision. On the branch release/bsp46.0-6.6.99-rt it contains -rt58. On a base of 6.12 or later its absence proves nothing on its own, because the series is upstream and no longer needs to be applied separately.

Which kernel lines does this automotive Linux BSP still publish?

Read on 12 September 2026, the public branches under the recent releases are 6.12 (6.12.19 under bsp46.0, 6.12.92 under bsp48.0) and 6.6 (6.6.99-rt under bsp46.0 and s32n7_bsp2.0). The 5.15 line was last published under bsp45.0 in October 2025.

Can I measure latency on the BSP as delivered?

Not with the kernel-side tracers. The shipped s32cc_defconfig sets # CONFIG_FTRACE is not set and # CONFIG_SCHED_DEBUG is not set, so the latency tracers are not built. A user-space tool such as cyclictest still runs, but you will have to enable tracing and rebuild before the kernel can tell you where the latency came from.

How do I confirm the preemption model on a board rather than in the source?

The BSP defconfig sets CONFIG_IKCONFIG_PROC=y, so the running kernel exposes its own configuration at /proc/config.gz. Decompress it and grep for the preemption symbols. That reflects the kernel actually booted, which a source tree does not.

Why is there no BSP 47.0?

The public numbering steps from bsp46.0 to bsp48.0, and a branch search for bsp47 returns no matches. The GitHub repositories, the BSP README and the manifest tags were checked and no public statement about the gap was found, so it is recorded here as an observation rather than explained.

Further reading

• Branch list, nxp-auto-linux/linux (primary) — https://github.com/nxp-auto-linux/linux/branches/all
• Release tags, nxp-auto-linux/auto_yocto_bsp (primary) — https://github.com/nxp-auto-linux/auto_yocto_bsp/tags
• BSP build instructions and manifest list, auto_yocto_bsp README (primary) — https://github.com/nxp-auto-linux/auto_yocto_bsp
• Active kernel releases and projected end-of-life dates, kernel.org (primary) — https://www.kernel.org/releases.html
• Linux 6.12 changelog, on the merge of real-time preemption — https://kernelnewbies.org/Linux_6.12