Mazda Connect Runtime Analysis (CMU Processes & Memory)
Measured on a Gen 6 CMU running v74.00.324A. These are live observations from a unit at idle, not datasheet figures.
Hardware (measured)
Section titled “Hardware (measured)”| Parameter | Value | Notes |
|---|---|---|
| CPU | i.MX6D dual Cortex-A9 @ 675 MHz | Below the NXP part’s rated maximum |
| Linux-visible RAM | 746 MB | ~258 MB carved off for the GPU/VPU |
| Filesystem | Datalight Reliance Nitro on FlashFX NAND | Not ext4 |
The i.MX6D is a 2012-era automotive SoC. The clock runs under the part’s ceiling, and a chunk of physical RAM never reaches Linux because it’s reserved for the Vivante GPU and the video processing unit. What’s left is what every service has to fit into.
Process landscape
Section titled “Process landscape”At idle: ignition on, UI interactive, no media playing, no phone connected.
| Metric | Value |
|---|---|
| Userspace processes | ~90–105 |
| RAM consumed | ~621 MB |
| Free RAM | ~190 MB |
| Largest single process | Opera browser (~53–56 MB) |
The headline number is the process count. The CMU runs ~100 userspace processes before you’ve touched anything, and many of them service hardware or backends that aren’t present.
Display stack
Section titled “Display stack”The CMU renders the HMI through Wayland, not X11:
- A Vivante GPU-native compositor owns the framebuffer.
- Opera Presto renders all HMI content as a single Wayland client.
- There’s no separate window manager — one fullscreen surface, composited directly.
The entire interface you see is a web page. The home screen, the audio source list, the settings tree: all of it is markup rendered by an embedded Opera engine talking to native services over the bus.
Where the memory goes
Section titled “Where the memory goes”Top resident consumers at idle:
| Category | Approx. RSS | Notes |
|---|---|---|
| Speech engine | ~48 MB | Required for voice commands |
| Satellite radio services | ~47 MB | Unused in most markets |
| Legacy streaming apps | ~39 MB | Aha, Pandora, Stitcher, Slacker — all defunct |
| Telematics services | ~38 MB | No hardware to talk to on most ND MX-5 |
| Browser (Opera) | ~53–56 MB | Varies with UI state |
| Bluetooth stack | ~25 MB | Active |
| Navigation/Maps | ~20 MB | Only if a nav SD card is present |
A large share of resident RAM belongs to services for things that no longer work. The legacy streaming apps point at backends that were shut down years ago. The satellite radio services run in markets that never had the receiver. Telematics initializes on cars that don’t have the modem. These processes still start, still allocate, and still sit in the run queue at boot — which is most of why a stock CMU is slow to become interactive and tight on free RAM. See Boot Chain for how that startup ordering plays out.
Storage
Section titled “Storage”| Partition | Size | Purpose |
|---|---|---|
| Root filesystem | 602 MB | OS and applications (read-only) |
| User data | 316 MB | Settings, logs, persistent state (read-write) |
| tmpfs | varies | Runtime temporary files, RAM-backed |
Root is mounted read-only, so runtime writes land in the user-data partition or in RAM-backed tmpfs. Full partition map is in Filesystem Layout.
Related
Section titled “Related”- Boot Chain — boot sequence and timing
- Services — service architecture and what each one does
- Filesystem Layout — partition structure
- Platform Overview — the CMU hardware in context