Putting functions that used to live on separate ECUs onto one SoC saves cost, wiring and weight — but only if those functions cannot disturb each other and can still talk when they must. Many platforms promise that; few suppliers can show it running. Requisimus has built and measured it on an NXP i.MX 8QuadXPlus: Linux, a Zephyr guest and a second Zephyr instance on the real-time core run side by side, and every claim in this article comes with the console output behind it.
| 3 | 0.10 ms | 64 Mbit/s | 1.1–4 µs | Real HW |
| Execution Domains | Inter-Guest Round Trip | TCP via Shared Memory | Isolated-Core Jitter | No Emulation |
Why Zephyr and Open-Source Building Blocks?
The first question we hear is why this stack is built on open-source components: Zephyr for the real-time side, Jailhouse for partitioning and Linux for the rich domain. Here is what that choice gave us on this project; each point rests on something we measured or found.
| No Licence Fees, Clear Terms Zephyr is Apache-2.0, Linux and Jailhouse are GPL-2.0: no per-unit fees. Apache keeps your code private; GPL asks you to share your changes. | Source You Can Read We solved every bring-up problem by reading the source, not by waiting for a support ticket. |
| Small, Reviewable Components The Jailhouse hypervisor is about 100 KB. A Zephyr guest is 37 KB, or 133 KB with a full TCP/IP stack. | Use What the Community Built Network stack, sockets and a shared-memory Ethernet driver already existed. Our network application is one 244-line file. |
| Port to New Silicon Yourself Upstream has no Cortex-M4 or Cortex-A35 target for this chip, so we added both: 16 files, about 330 lines. | Reproducible, Under Your Control Pinned versions, scripted builds, five cell configurations rebuilt bit-identically. You decide when to take a fix. |
Honest Trade-Offs
Open source is not free of work. Components have to be integrated and tracked (this is what we do), licence obligations have to be managed, and none of it comes with a safety certification: a safety case needs its own evidence. Community support is not a contractual service level, so production programmes usually pair these components with engineering support from a partner.
The Challenge
A modern SoC has more than enough compute to host an infotainment stack, a real-time function and a gateway at the same time. Sharing silicon is not the same as sharing it safely, though: functions that used to live on separate ECUs must not be able to disturb each other, and must still be able to exchange data when they have to.
Many platforms promise exactly that. One critical question remains:
Can your supplier show it running — isolated, connected and measured — on real hardware?
Three things decide whether a consolidation concept holds up. Each function must be genuinely isolated: cores, memory and devices belong to exactly one domain, and a fault stays there. Isolated functions must still exchange data fast enough, through channels you control and can inspect. And the whole setup must be reproducible from sources, not just demonstrated once.
The NXP i.MX 8QuadXPlus is a demanding test: four Cortex-A35 application cores, a Cortex-M4 real-time core and a System Controller that decides who owns which resource. We used it to build the architecture below, and to measure it.
What “Consolidated” Does Not Automatically Mean
- A hypervisor is installed does not mean two guests cannot still share a device or a memory region they should not.
- Two domains “communicate” does not mean the channel pairs with the right peer: it can silently pair with the wrong one.
- A guest “runs” does not mean its timer is right: the frequency may have been assumed rather than measured.
- A build that works on one machine does not mean its toolchain defaults produce a valid bare-metal image, or that its files survive a restart.
Every item on this list happened to us during bring-up. Each one was caught because we measured instead of assuming.
Proven on the Platform We Built
Requisimus does not describe multi-core architectures in the abstract. We built and measured this one on a real NXP i.MX 8QuadXPlus development board: Linux and a Zephyr guest on the Cortex-A35 cores under the Jailhouse hypervisor, and Zephyr on the Cortex-M4.
| Linux root cell + Jailhouse Linux 6.18 boots first and owns cores 0–2. Jailhouse, enabled at boot by a service, takes a core away for a guest cell. The effect is visible on the running system: three CPUs for Linux, one for the guest. | Zephyr 4.1 on a Cortex-A35 core Upstream Zephyr has no A-core target for this chip, so we wrote an out-of-tree SoC and board port. The guest boots inside a Jailhouse cell, prints through the hypervisor and keeps time to within 0.14 % of the board clock. | Zephyr on the Cortex-M4 A vehicle-signal service with a software supervisor runs on the real-time core and is read from Linux over RPMsg. A 19-check automated test passes against it over Ethernet. |
Architecture — Three Domains, Two Links
Figure 1 — A tester PC reaches the Linux root cell over Ethernet. Linux talks to the real-time Zephyr core over RPMsg (OpenAMP) and to the Zephyr guest on the fourth Cortex-A35 core over ivshmem Ethernet: an Ethernet link carried over shared memory, with virtual-PCI interrupts. The Jailhouse hypervisor partitions the A35 cores, memory and devices; the System Controller partitions the M4. The four boxes at the bottom are measurements from the board.
How We Build and Validate Multi-Core Systems
| 01 | Boot Path to the Hypervisor U-Boot starts the real-time core, then boots a Linux kernel with KVM switched off so that Jailhouse can own the hypervisor level. Nothing is saved in the bootloader: a power cycle returns the known-good setup. |
| 02 | Partitioning Cores, RAM and devices are assigned per cell and checked on the running system (CPU counts, cell list) and in the hypervisor’s own log. |
| 03 | Guest Bring-Up An out-of-tree Zephyr SoC and board for the Cortex-A35, a cell configuration, and a console through a hypervisor call, so no UART is needed. |
| 04 | Timing The 8 MHz system counter is confirmed from the kernel log and by comparing the guest’s clock with the board’s: a ratio of 1.0014 over 44 seconds. |
| 05 | Cross-Domain Link ivshmem (virtual PCI device, shared memory, interrupts) between Linux and Zephyr. The handshake state machine — reset, init, ready, run — is checked on both sides. |
| 06 | Real Traffic UDP and TCP echo with data verification: 300 datagrams without loss, and 2 MB over TCP returned byte-identical. |
| 07 | End-to-End Signal Path A value written from a PC travels through the gateway to the M4, back through Linux and over the shared-memory link to the Zephyr guest. |
| 08 | Reproducibility Documented build from sources, a deployment that checks every file’s checksum on the target, and patches proven on a fresh clone: five cell configurations rebuilt bit-identically. |
What the Console Actually Shows
A claim such as “the cores are isolated and connected” is not evidence. What matters is the console output that shows it. The four captures below are real, taken from our bench runs (the column spacing of the cell tables is narrowed for the page, the content is unchanged); the addresses are those of the private link between the two domains, and no customer data is shown.
1) Partitioning — a Core Leaves Linux and Goes to the Guest
| # Linux owns all four cores until the guest cell is created $ ./jailhouse cell list ID Name State Assigned CPUs Failed CPUs 0 imx8qxp running 0-3 $ ./jailhouse cell create imx8qxp-zephyr-net.cell $ ./jailhouse cell load zephyr-net zephyr-net.bin -a 0xdf700000 $ ./jailhouse cell start zephyr-net $ ./jailhouse cell list ID Name State Assigned CPUs Failed CPUs 0 imx8qxp running 0-2 1 zephyr-net running 3 $ nproc 3 |
2) The Guest Finds the Shared-Memory Device and Talks to Linux
| # Zephyr guest, through the hypervisor console (excerpts of two runs on the same setup) I: [00:01.0] 110a:4106 class ff subclass 0 progif 1 rev 0 Type0 multifunction false I: Enabling INTx IRQ 123 (pin 2) I: ivshmem: id 1, max_peers 2 I: shmem queue: desc len 0x800, header size 0xD080, data size 0x71F80 *** Booting Zephyr OS build v4.1.0 *** Hello from Zephyr as a Jailhouse guest on mekmimx8qx_a35/mimx8qx6a35, with ivshmem Ethernet t=2: link up, ping 1 (ret 0) replies 1 rtt 185 us | udp echoed 0, tcp conns 0 bytes 0 | … t=4: link up, ping 2 (ret 0) replies 2 rtt 173 us | udp echoed 0, tcp conns 0 bytes 0 | … # from Linux $ ping -c 50 -i 0.1 192.168.19.2 50 packets transmitted, 50 received, 0% packet loss, time 5115ms rtt min/avg/max/mdev = 0.080/0.103/0.246/0.025 ms |
3) Live Vehicle Data From the M4 Reaches the Zephyr Guest Through Linux
| # The speed is set from a PC and crosses gateway, M4, RPMsg, Linux and the shared-memory link; the M4 computes rpm = speed x 40 + 800 $ vsig_net_client.py BOARD set speed_kph 123 {“ok”: true, “name”: “speed_kph”, “value”: 123} t=32: link up, … | gateway: speed 123 km/h, rpm 5720 (ok 30, errors 0) $ vsig_net_client.py BOARD set speed_kph 45 t=36: link up, … | gateway: speed 45 km/h, rpm 2600 (ok 34, errors 0) |
4) A Faulty Guest Is Stopped by the Hypervisor — Linux Keeps Running
| # An early, misplaced PCI window made a guest read an address it does not own Unhandled data read at 0x80100000(2) FATAL: unhandled trap (exception class 0x24) Parking CPU 3 (Cell: “ivshmem-demo”) # issued over SSH to the still-running Linux $ ./jailhouse cell list ID Name State Assigned CPUs Failed CPUs 0 imx8qxp running 0-2 1 ivshmem-demo failed 3 3 |
Trace 1 is what consolidation means in practice: one core leaves Linux and belongs to the guest. Traces 2 and 3 show that isolated domains still exchange data, with numbers. Trace 4 is the point of a hypervisor: a guest that goes wrong is parked, and the other domains carry on.
Figure 2 — Serial console of a bare-metal timer guest on the isolated core: timer jitter between 1.1 and 4.0 µs while Linux runs on the other cores.
What Only Hardware Shows
These are the details a datasheet does not give you, found and fixed during this work:
- Shared-memory peers are matched by PCI address, not by memory address. A guest whose virtual network device sat in the wrong slot paired with the wrong peer: Linux counted zero interrupts until we moved it.
- An empty PCI slot reads as all ones. Zephyr’s bus scan took that for a multi-function host controller and found nothing.
- Address windows have three constraints at once: outside Linux’s reserved memory, outside the guest’s mapped regions, and away from the guest library’s fixed communication page. Our first two choices failed (one crashed the kernel with a bus error); the third works.
- Toolchain defaults matter. A distribution compiler’s hardening options (stack protector, branch protection, outline atomics) each broke the bare-metal link.
- A file copied shortly before a restart came back as zeros. Our deployment now syncs and verifies every checksum on the target.
Why It Matters
| Consolidation With Proof Isolation and communication are shown on running hardware, with logs, instead of being asserted in a slide. | Open Building Blocks Linux, Jailhouse and Zephyr are open-source components under GPL-2.0 and Apache-2.0 licences; the integration work, the port and the tooling are what we add. |
| Reproducible by Your Team Sources, patches, build and deployment scripts and a step-by-step guide. We verified that the patches apply to a fresh checkout and rebuild identical configurations. | Honest Boundaries This is static partitioning on a development board, not a safety certification, and long-duration stability testing is a separate next step. We state what has been verified and what has not. |
Techniques & Technologies
- Hypervisor & Partitioning: Jailhouse (NXP fork), EL2, cells, System Controller (SCU), device tree
- Operating Systems: Linux 6.18 (root cell), Zephyr 4.1 (Cortex-A35 guest and Cortex-M4)
- Inter-Core Communication: OpenAMP / RPMsg, ivshmem (virtual PCI), virtio rings, UDP / TCP
- Build & Tooling: U-Boot, west / CMake, cross-compilation, checksum-verified deployment
Engineering Facts
| Execution Domains | 3 |
| Inter-Domain Links | RPMsg · ivshmem |
| Gateway Checks | 19 / 19 pass |
| Cell Configs Rebuilt | 5, bit-identical |
| Evidence | Real hardware |
Ready to Consolidate Functions on One SoC — With Evidence?
Consolidation is not just a block diagram — it is a measurement. Tell us which functions you want to bring together and on which SoC; we will show you what holds on real hardware.
Get in touch:
📧 basavaraj.tarihalli@requisimus.com
Thanks for reading..!
requisimus | India