Enabling QEMU emulation for i.MX95 19x19 EVK (community project) What actually happens between powering on an i.MX95 system and reaching a Linux login prompt? The answer involves far more than a bootloader and a kernel. The Boot ROM must locate and interpret the boot containers, the Cortex-M33 System Manager must initialize and manage platform resources, the Cortex-A55 must progress through SPL, TF-A, OP-TEE, and U-Boot, and only then can Linux initialize the system and mount its root filesystem. This QEMU-based i.MX95 emulation turns that otherwise difficult-to-observe sequence into a reproducible virtual laboratory for students, hobbyists, and engineers who want to study the complete boot chain without relying entirely on physical hardware.
This community project (third-party, not an NXP product) adds QEMU-based i.MX95 emulation focused on that complete firmware journey. Rather than directly loading a kernel or staging each firmware component independently, the emulation starts from a Yocto-generated WIC image, processes its boot containers, executes the System Manager firmware, and preserves the handoffs that bring the A55 cluster online. The referenced third-party repository extends QEMU with functional emulation of the NXP i.MX95 SoC and the i.MX95 19x19 LPDDR5 EVK - embeddedPatronus/imx95-qemu: i.MX95 Qemu emulation for the complete firmware boot chain, from ROM and System Manager through TF-A, OP-TEE, U-Boot, and Linux. The project focuses on executing, observing, and debugging the complete production-style firmware boot chain from a bootable SD or eMMC image. This qemu model is intended for:-
The model is intended for:
for experimentation and learning [not a replacement for validation on NXP hardware]
Boot-image and BSP testing
System Manager and SCMI development
TF-A and OP-TEE debugging
Secure-world SMP analysis
U-Boot and Linux platform development
Pre-silicon and hardware-scarce development
Education about modern heterogeneous Arm SoCs
The model can help investigate questions such as:
Did the System Manager receive correct handover information?
Did SPL receive correct passover information?
Did an SCMI request reach the M33?
Did the System Manager provide a valid response?
Did the System Manager program the correct A55 reset vector?
Did the target CPU leave CPUWAIT?
Did TF-A restore the expected context?
Did OP-TEE select the correct per-core state?
Did Linux mount the intended root filesystem?
BSP regression testing
A complete WIC image can be tested as the release artifact [functional smoke test only. not release qualification] Refer to Building Qemu section in the README of the repo to build the emulation model. To run qemu emulation of iMX95EVK:-
cd build
./qemu-system-aarch64 -M imx95-evk -drive if=sd,index=0,file= ,format=raw -display none -serial pty -serial stdio
-- Expected logs:-
char device redirected to /dev/pts/11 (label serial0)
U-Boot SPL 2026.04-lf_v2026.04+g6eeef838dac+p0 (Jun 02 2026 - 15:03:39 +0000) SYS Boot reason: por, origin: -1, errid: -1 Normal Boot Trying to boot from MMC1 Boot stage: Primary Image set: 0, offset: 0x8000 Load image from MMC/SD 0xf5800 NOTICE: BL31: v2.14.1(release):lf-6.18.20-2.0.0 NOTICE: BL31: Built : 12:42:19, Jun 8 2026
U-Boot 2026.04-lf_v2026.04+g6eeef838dac+p0 (Jun 02 2026 - 15:03:39 +0000)
CPU: NXP i.MX95 Rev1.0 A55 at 1800 MHz CPU: Consumer temperature grade (0C to 95C) - invalid sensor data Model: NXP i.MX95 19X19 board ... ...
The example command configures two serial consoles:
"-serial pty -serial stdio" The serial ports are assigned as follows:
Serial option Console First serial port, -serial pty Cortex-M33 System Manager debug console Second serial port, -serial stdio Cortex-A55 firmware and Linux console
When QEMU starts, it prints the pseudo-terminal allocated to the System Manager console. Example:
char device redirected to /dev/pts/11
To access the SM console on another tab:-
screen /dev/pts/11
You can therefore observe both processing domains at the same time:
Terminal 1
Cortex-A55 console SPL, TF-A, OP-TEE, U-Boot and Linux logs
Terminal 2
Cortex-M33 System Manager console System Manager logs and interactive commands
What actually happens between powering on an i.MX95 system and reaching a Linux login prompt? The answer involves far more than a bootloader and a kernel. This QEMU-based i.MX95 emulation turns that otherwise difficult-to-observe sequence into a reproducible virtual laboratory for students, hobbyists, and engineers who want to study the complete boot chain without relying entirely on physical hardware. IMX95EVK
View full article
