AUTOSAR Classic Beside Linux on the S32G3: Which Core Gets the Safety Function?

An engineer bringing up a vehicle gateway or zonal controller on an NXP S32G3 has two processor complexes on one die: up to eight Cortex-A53 application cores, and up to four Cortex-M7 cores provided as dual-core lockstep pairs. Linux boots on the A53 clusters from NXP’s public Yocto manifests. In most designs, AUTOSAR Classic runs on the M7 cores. This post asks why the partition falls there, who decided it, and what the boundary between the two halves now has to carry.

What NXP’s S32G3 documents say about the split

The S32G3 fact sheet describes “up to 8 Arm Cortex-A53 cores” in two clusters “with optional cluster lockstep”, supporting “high-level operating systems”, and “up to 4 Arm Cortex-M7 dual-core lockstep cores” supporting “real-time processing and safety operating systems”.

The S32G software enablement brochure is more direct. For the Cortex-M7 cores it states: “Real-time applications will run here on an OS like AUTOSAR and FreeRTOS”. For the Cortex-A53 cores: “High-level operating systems like Linux will run here”, with Adaptive AUTOSAR on top. Its S32G3 block diagram labels the A53 side with Linux, QNX, INTEGRITY and VxWorks, and the M7 side with AUTOSAR 4.4 and FreeRTOS. The S32 Safety Software Framework can run on either core type, but “in most automotive applications, one of the Arm Cortex-M7 cores is designated as the safety core running SAF”.

The most useful fact is the brochure’s software quality table. Class A is “Functional safety products — ISO 26262 compliant” and contains the Safety Software Framework, the Real Time Drivers and the Inter-Platform Communication Framework (IPCF). Class B, SPICE-compliant, holds the network and security firmware. Class O is the “Open-source software class”, and the Linux BSP sits there with the USB, SDHC and TCP/IP stacks. The NXP Automotive Linux BSP product brief (Rev 3.0, February 2023) states that the BSP follows processes that are “Automotive-SPICE (tailored for open source), IATF16949 and ISO9001 compliant”, and makes no ISO 26262 statement.

So the silicon vendor made the partitioning decision before the integrator starts, and wrote it down. The ISO 26262 claims attach to the drivers, the safety framework and IPCF, and the Real Time Drivers are delivered for the M7, where the AUTOSAR Classic stack sits.

The strongest case for AUTOSAR Classic on the safety core

Before any Linux-side response, here is why a functional-safety engineer puts the control path on a lockstep M7 running AUTOSAR Classic. These are engineering reasons.

The first is the hardware. A lockstep pair executes the same instructions on two cores and compares the results, so a random hardware fault in one core is detected as a mismatch instead of propagating as a wrong answer. The A53 clusters offer lockstep as an option; on the M7 side, lockstep is the form in which the cores are provided.

The second is that the AUTOSAR Classic operating system is a static system. The Specification of Operating System, Classic Platform release R25-11, published on 27 November 2025, defines an OS whose tasks, interrupt service routines, alarms, schedule tables and counters are all declared in configuration and grouped into OS-Applications. Nothing is loaded at run time, so every schedulable entity can be enumerated in advance.

The third, and the most important, is how that specification treats timing faults. Section 7.7.2 argues that deadline monitoring is insufficient because the task that misses its deadline “is therefore not necessarily the Task/ISR that has failed at runtime, it is simply the earliest point that a timing fault is detected”. Its worked example shows a correct task missing its deadline because two faulty ones overran. So the specification controls the causes directly. Execution time protection enforces a statically configured upper bound, the Execution Budget, on each task and category 2 interrupt. Locking time protection enforces a Lock Budget on how long resources are held and interrupts disabled. Inter-arrival time protection enforces a lower bound, the Time Frame, between successive activations of a task and arrivals of a category 2 interrupt, which bounds how often a faulty peripheral’s interrupt can take the core.

The fourth is that a violation has a defined consequence. On a memory violation, budget overrun or stack fault the OS calls a ProtectionHook, and the specification enumerates its permitted returns: terminate the faulty task or interrupt, terminate the whole OS-Application with PRO_TERMINATEAPPL, or shut the OS down with PRO_SHUTDOWN. Memory protection is defined per OS-Application, and the OS “shall prevent write access to its own data sections and its own stack from non-trusted OS-Applications”. Vector’s MICROSAR Classic product catalogue maps these features onto four scalability classes: SC1 schedule tables, SC2 adding timing protection, SC3 adding memory protection, SC4 both. The specification states that OS-Applications are only mandatory in Scalability Classes 3 and 4.

The fifth is assessed supplier evidence. Vector’s press release of 24 July 2024 states that exida has “once again certified” MICROSAR Classic Safe under ISO 26262 up to ASIL D, for the basic-software modules in its assessed scope, and that this assessment for the first time evaluated a method establishing upper bounds on module execution time. NXP’s brochure lists Elektrobit, Vector and ETAS among its AUTOSAR Classic partners for S32G, and its Real Time Drivers can be configured with EB tresos Studio “and any AUTOSAR-compliant configurator”. An integrator can choose among AUTOSAR Classic stacks on Class A drivers.

The Linux position on the A53 side, on its own terms

The kernel has real mechanisms here. SCHED_DEADLINE, in the kernel’s own documentation, schedules a task with runtime, deadline and period parameters so that it “should receive runtime microseconds of execution time every period microseconds”. It uses the Constant Bandwidth Server algorithm, and a task that exhausts its runtime is “throttled” until its next scheduling deadline, which protects other tasks from its overrun. With admission control, a task whose runtime covers its worst-case execution time gets the “hard schedulability property”, and a task can ask to be told about overruns through SIGXCPU.

That is closer to the AUTOSAR Classic Execution Budget than many Linux engineers realise. The differences are in what surrounds it. The documentation states that without admission control “no guarantee can be given”, and that under overload the guarantee “cannot be respected”. The reaction to an overrun is throttling, not a configured decision to terminate a defined group of components. The document describes no lock budget on holding locks or disabling interrupts, and no per-interrupt arrival bound like the AUTOSAR Classic Time Frame. And the set of schedulable entities is open: kernel threads, workqueues, softirq processing and user processes appear at run time.

The shipped configuration matters as much as the mechanism. Read on 13 November 2026, the s32cc_defconfig on NXP’s kernel branches release/bsp48.0-6.12.92 and release/bsp47.0-6.12.92 sets CONFIG_PREEMPT=y and does not set PREEMPT_RT; both leave CONFIG_FTRACE and CONFIG_IOMMU_SUPPORT unset. The real-time kernel is still published on the older series: release/bsp47.0-6.6.99-rt carries a localversion-rt of “-rt58”. We traced that 6.12 transition in the earlier post on the S32 BSP’s move to 6.12 without a real-time series. The point here is narrower: an engineer arguing Linux timing on this part starts from a preemptible but not real-time kernel, with no tracing in the default build.

These commands run on the build host and read those facts from NXP’s public repositories.

raghu@techveda.org:~$ git ls-remote --heads https://github.com/nxp-auto-linux/linux | grep -E "bsp4[78]"
0dbdad6f0f4bc31371b1a416fb6678ae83802a7b	refs/heads/release/bsp47.0-6.12.92
1ea3efb7d1409fd997dff589f32309b8e7f33e10	refs/heads/release/bsp47.0-6.6.99-rt
7fab414d3e11122a70fba8c7c7db044edb014946	refs/heads/release/bsp48.0-6.12.92
raghu@techveda.org:~$ curl -sS https://raw.githubusercontent.com/nxp-auto-linux/linux/release/bsp48.0-6.12.92/arch/arm64/configs/s32cc_defconfig | grep -E "PREEMPT|IOMMU_SUPPORT|CONFIG_FTRACE"
CONFIG_PREEMPT=y
# CONFIG_IOMMU_SUPPORT is not set
# CONFIG_FTRACE is not set

The same defconfig enables CONFIG_IKCONFIG_PROC, so the running kernel can be checked on the board. This runs on the target.

root@s32g399aevb3:~# zcat /proc/config.gz | grep -E "CONFIG_PREEMPT|CONFIG_IOMMU_SUPPORT"

A Yocto build can add configuration fragments, so an image may differ from the branch.

The honest summary: for the ASIL D control function on an S32G3, Linux is not the right tool today. Not because the kernel lacks scheduling mechanisms, but because the vendor has not put the BSP in its safety class, the shipped kernel is not configured for bounded latency, and the kernel has no equivalent of a statically enumerated system whose budgets, violation reactions and containment groups are fixed in configuration. What Linux does well on the A53 side is everything that changes: Ethernet services, service-oriented communication, Adaptive AUTOSAR, containers and update handling.

The boundary beside AUTOSAR Classic is now a safety element

Putting the safety function on the M7 does not remove Linux from the safety analysis. Linux stops performing the function and becomes a source of interference the function must be protected from, and that protection has to hold at the boundary.

On the S32G the boundary is IPCF, which the brochure says lets applications on multiple cores “communicate over various transport interfaces (shared memory, PCIe, Ethernet, etc.)”. NXP places IPCF in Class A for both “A53/M7”. A shared-memory channel is a coupling path: a faulty Linux process can write wrong data, write it late, write it too often, or stop writing. Each case has to be detected on the M7 side or shown to be harmless, and the detection belongs in the AUTOSAR Classic partition, where execution budgets and arrival-rate bounds exist.

The hardware configuration has to support this. The block diagram lists 16 XRDC domains; the reference manual defining that domain model was not among the public documents read for this post, so its detail is not described here. The principle does not depend on it. If Linux, or a DMA-capable device under Linux’s control, can write into memory the M7 partition owns, AUTOSAR Classic memory protection on the M7 cannot stop it, because that protection constrains the M7’s own accesses. Whatever hardware mechanism confines the A53 side is integrator configuration and belongs in the safety case; the default defconfig leaving CONFIG_IOMMU_SUPPORT unset shows that it is not a default.

Both halves also share the 20 MB of system SRAM, the DDR interface and the interconnect. M7 execution budgets bound how long its tasks run, not how long its memory accesses take while Linux saturates a shared path. Timing evidence for the safety partition has to be measured with Linux under worst realistic load, and the analysis of dependent failures across the boundary is item-level work no supplier certificate contains.

What changed, and when

The AUTOSAR Classic OS specification itself keeps moving. Its change history records that R24-11, dated 27 November 2024, removed the option to restart an OS-Application and added a new PRO_PREVENT_ARRIVAL_RATE return value, and that R25-11, dated 27 November 2025, added a timing protection extension for aperiodic servers. Vector dates the first ASIL D certification of MICROSAR Classic Safe to 2016; its 24 July 2024 release describes the second follow-up assessment by exida, which added execution-time upper bounds and multi-core separation modules to the assessed scope.

On the Linux side, NXP’s public download page for “Automotive SW for S32G3 – Linux BSP”, read on 13 November 2026, still lists Rev 43.0.0 dated 12 December 2024. The GitHub manifests are well ahead: bsp48.0 is tagged 30 July 2026, and bsp47.0 is tagged later, on 18 September 2026, with a 6.12.92 branch and a 6.6.99-rt branch. When this beat checked the same repositories on 12 September 2026, no bsp47.0 tag or branch existed. On the A53 alternatives, QNX publishes release notes for a QNX SDP 8.0 BSP for the S32G399A RDB3, edition dated 9 January 2026; they list drivers and known issues and do not state whether the BSP falls within any safety certificate, and this post makes no such claim.

What this does not settle

NXP’s S32G safety documentation, including the Safety Software Framework, is distributed through NXP’s secure content programme on request, so this post does not characterise its assumptions of use. Vector’s MICROSAR Classic page offers a “Download Certificate” link beside its functional-safety text, but the document behind it, read on 13 November 2026, is SGS-TÜV Saar certificate FS/71/220/25/1956, dated 27 January 2026, covering MICROSAR Classic and MICROSAR HSM against ISO/SAE 21434:2021, the cybersecurity standard, not ISO 26262. No public exida certificate number for the ISO 26262 assessment was found on Vector’s site or by search, so the functional-safety position above rests on Vector’s own press release. The brochure is undated; only its partner list is dated, 14 March 2023.

Nor does this post argue that Linux can never perform a safety function. Earlier posts on this beat examined Linux offerings with scoped assessments at ASIL B. The narrower claim is that on this part, for the highest-integrity control path, the vendor’s documents, the AUTOSAR Classic specification and the shipped kernel configuration all lead to the same answer.

Key takeaways

• NXP’s S32G brochure places safety software on the lockstep Cortex-M7 cores and Linux on the Cortex-A53 cores, with the Linux BSP in “Class O”, outside its ISO 26262 Class A.
• AUTOSAR Classic OS R25-11 defines Execution Budgets, Lock Budgets and inter-arrival Time Frames, and a ProtectionHook that can terminate an OS-Application or shut the OS down.
• SCHED_DEADLINE gives Linux a real runtime budget, but its overrun reaction is throttling and it has no lock budget or per-interrupt arrival bound.
• NXP’s public 6.12.92 branches for bsp47.0 and bsp48.0 build with CONFIG_PREEMPT, not PREEMPT_RT, and with ftrace and IOMMU support off.
• The IPCF channel and the hardware access configuration between the two halves are part of the safety argument, and both are integrator configuration.

Frequently asked questions

Why does the safety function on an S32G3 usually run on a Cortex-M7 rather than under Linux?
NXP’s software brochure states that in most automotive applications one Cortex-M7 is designated as the safety core, and it places the Linux BSP in its open-source quality class rather than its ISO 26262 class. The M7 cores are also provided as lockstep pairs.

What does AUTOSAR Classic timing protection do that deadline monitoring does not?
It bounds the causes of a missed deadline instead of reacting to the miss: an Execution Budget per task or interrupt, a Lock Budget on holding resources or disabling interrupts, and a Time Frame between arrivals. The specification explains that the task which misses a deadline is often not the one that failed.

Is SCHED_DEADLINE the Linux equivalent of an AUTOSAR execution budget?
It is the closest Linux mechanism, giving a task a runtime budget per period and throttling it when the budget is exhausted. It does not provide a lock budget, a per-interrupt arrival bound, or a configured reaction such as terminating a group of components.

Does running the safety function on the M7 take Linux out of the safety analysis?
No. Linux becomes a potential source of interference, so the IPCF channel, the hardware access configuration and the shared memory system between the two halves all have to be covered by the safety argument.

Further reading

• NXP, S32G Vehicle Network Processors Software Enablement Brochure (primary; read 13 November 2026)
• NXP, S32G3 fact sheet (primary)
• NXP, Automotive Linux BSP Product Brief, Rev 3.0 (primary)
• AUTOSAR, Specification of Operating System, Classic Platform R25-11 (primary specification)
• Vector, 24 July 2024 press release on the exida ASIL D recertification
• Vector, MICROSAR Classic product page and catalogue
• Linux kernel documentation, Deadline Task Scheduling (primary)
• NXP auto_yocto_bsp tags and nxp-auto-linux kernel branches (primary)
• QNX SDP 8.0 BSP for NXP S32G399A RDB3 release notes