Hi,
we are currently using the NXP QorIQ Linux kernel from the linux-6.12-rt branch, but we would like to move to a newer kernel version, possibly Linux 6.18.
I have a few questions regarding the RT kernel support and branch strategy:
What exactly is the difference between linux-6.12-rt and lf-6.12.y?
Is a separate linux-6.18-rt branch planned, similarly to linux-6.12-rt?
If not, is lf-6.18.y intended to be used directly with CONFIG_PREEMPT_RT=y?
My understanding is that linux-6.12-rt contains additional PREEMPT_RT-related changes compared to lf-6.12.y. However, starting with Linux 6.12, the core PREEMPT_RT support has been merged into the upstream kernel:
https://kernel-internals.org/locking/preempt-rt/
At the same time, I can see that RT-specific development and stable RT patch releases still continue separately upstream.
Given this, I would like to understand how this is handled in the newer NXP QorIQ releases.
For Linux 6.18, should we simply use the lf-6.18.y branch with CONFIG_PREEMPT_RT=y, with all NXP-specific changes required for PREEMPT_RT already included there?
Or is a separate QorIQ RT branch/release still planned, containing additional RT patches on top of lf-6.18.y?
If no separate RT branch is planned, are there any additional RT patches that NXP recommends applying on top of lf-6.18.y?
Hello,
For QorIQ/Layerscape, do not assume that lf-6.18.y plus CONFIG_PREEMPT_RT=y is equivalent to NXP’s supported RT release. NXP’s current Real-Time Edge material shows Linux PREEMPT_RT 6.18 releases based on LF 6.18, while internal development tracks a separate downstream RT patch stack.
Use the matching NXP 6.18 RT release, preferably the latest one available for your QorIQ platform. Compare your current linux-6.12-rt tree against the corresponding LF 6.18 base, but do not assume that enabling CONFIG_PREEMPT_RT=y alone includes all NXP-specific RT changes.
Also validate:
ARCH_SUPPORTS_RT;The upstream article’s main qualification is also relevant: PREEMPT_RT became mainline-selectable in 6.12, but support is architecture-dependent and does not imply that every vendor driver has been validated for deterministic behavior
Regards
So, if you mean the next 6.18-based RT update, the current roadmap points to Real-Time Edge 3.6 in December 2026.
Note that the standard i.MX Linux BSP—not RT—already has newer 6.18 releases, including 6.18.37 on September 24, 2026.
Regards