Gen 6 Mazda Connect Boot Sequence

On a stock Gen 6 MZD Connect CMU (firmware v74.00.324A), the home screen appears around 25 seconds after ignition-on, the unit becomes fully responsive (touch-ready) around 48 seconds, and wireless CarPlay connects around 71 seconds. Most of that is not the hardware struggling — it is the system walking a startup dependency graph that was laid out in 2014 and never revisited, and piling nearly all of that work onto a single processor core while a second core sits with spare capacity. This page traces that graph, phase by phase, and marks which waits are physical and which are bookkeeping.

ScreenTune’s performance build moves full responsiveness up to ~32 s and CarPlay to ~55 s on the same unit — full responsiveness about 16 seconds sooner, CarPlay about 16–20 seconds sooner (typically ~16, up to ~20 on a good boot), every start. The single biggest lever is how the two cores are used; that is the focus of this page.

The hardware

The CMU (Connectivity Master Unit) is an embedded computer behind the dash, built for Mazda by JCI (Johnson Controls, the tier-1 supplier).

• SoC: NXP i.MX6 — dual-core ARM Cortex-A9 at ~1 GHz. Roughly a 2013-class smartphone.
• RAM: 764 MB, no swap. Every process fits in physical memory or the kernel kills something.
• Storage: internal eMMC flash for the OS and apps.
• OS: Linux 3.0.35, a JCI-customized build.

It is not underpowered for the job. The constraint is how it spends its first 30 seconds — and, crucially, which core does that spending. See /hardware/platform/ for the full SoC and board breakdown.

The dual-core scheduling problem

The i.MX6 has two cores, but from a cold start the stock software does not use them evenly. It piles almost all of its startup work onto the first core, which sits pinned at 100% through the critical window, while the second core has real headroom. We confirmed this directly: during early boot the first core is essentially maxed out while the second is largely idle.

That imbalance is what actually delays Wi-Fi and CarPlay. Bringing up the access point and the CarPlay session is not heavy work, but it has to wait its turn behind everything else queued on the busy first core — a traffic jam on one lane while the next lane sits open.

ScreenTune’s main win is to move the Wi-Fi and CarPlay bring-up onto the second, less-busy core, so it runs right away instead of waiting in line. This is the principal reason CarPlay arrives ~16–20 s sooner; it is a scheduling change, not a matter of disabling services. The dependency-graph edits below (the AHA Radio gate, the fixed sleeps, trimming absent-hardware services) are real and additive, but the core rebalancing is the dominant lever.

The Service Manager and the dependency tree

The CMU does not just power on and draw the screen. Startup is driven by the Service Manager (SM), which reads a configuration file enumerating ~100 userspace services, each declaring the services that must already be running before it may start.

It is a dependency graph, and the SM resolves it strictly: a service blocks until every prerequisite reports ready. The config file is the boot time — change the edges in that graph and you change how long ignition-to-interactive takes. The full chain from power-on through the SM handoff is mapped in /internals/boot-chain/; the per-service inventory is in /internals/services/.

The boot phases

Startup resolves into roughly five phases. Each must complete before the next begins, because of the dependency edges between them.

Phase 0 — Hardware init (0–3 s)

SoC brings up, kernel loads, basic peripherals get configured. Fast, and not addressable from userspace.

Phase 1 — Audio and settings (3–10 s)

The audio subsystem initializes first: DSP, volume state, and the audio routing framework. It has to be early because nearly everything downstream produces sound: radio, Bluetooth, navigation, CarPlay. The settings service starts alongside it, loading saved preferences from flash.

Phase 2 — Screen on (10–18 s)

First pixels. The main HMI application, jciMMUI, starts. It depends on:

• audio ready (UI sounds),
• settings loaded (user preferences),
• the radio service running (main menu).

Before jciMMUI is up you see a splash or nothing. When it comes up, the system raises an internal milestone, stage_3 (“HMI displayed”). Several services gate on stage_3 before they will start — which is where the avoidable waiting begins.

Phase 3 — Bluetooth (18–25 s)

With the screen up, the Bluetooth stack starts:

1. dmserver — device manager, talks to the Bluetooth radio hardware.
2. BDS (Bluetooth Device Service) — uploads a ~46 KB firmware patch over a serial wire to the TI combo chip. This is a physical transfer; its floor is set by the link, not the CPU.
3. jciPA — phone application: calls and contacts.
4. jciBCA — Bluetooth Connection Automator: pairing and reconnection.

BDS waits for stage_3 before it starts. There is no hardware reason for this — pushing firmware to the Bluetooth chip has nothing to do with the display. It is a resource-priority decision: bring the screen up first, then start the radios.

Phase 4 — WiFi and CarPlay (25–35+ s)

This is where the schedule wastes the most time.

In the stock graph, WiFi cannot start until AHA Radio finishes initializing. AHA Radio was a streaming partner Mazda integrated in 2014; the service shut down years ago. The CMU still waits for it at every boot.

Bluetooth ready
  → jciBCA (connection manager)
    → AHA Radio app (defunct — still initializes)
      → WiFi modules load
        → WiFi access point starts
          → phone can connect

WiFi and Bluetooth share one combo chip but use entirely separate interfaces — WiFi over an SDIO data bus, Bluetooth over a serial UART. They have no hardware reason to serialize. The config makes WiFi wait for Bluetooth, which waits for the screen, which waits for audio. A single-file line where the hardware would allow parallel lanes.

Once WiFi does start, more delay stacks up:

• Module loading: five WiFi kernel modules load sequentially (~2–5 s).
• Hard-coded sleeps: the access-point startup script contains three sleep 2 calls — wait two seconds and assume it worked. That is 4–6 s of doing nothing measurable.
• Phone handoff: once the AP is live, the iPhone discovers it over Bluetooth, receives WiFi credentials, joins the network, and opens the CarPlay session — another 5–8 s, governed by Apple’s protocol and not addressable from the car side.

Where the time goes

The phase ranges above describe the order of work, not wall-clock milestones. Measured end to end on the same CMU, a stock wireless-CarPlay boot lands at these typical milestones — and the ScreenTune build at these:

Milestone	Stock (typical)	ScreenTune (typical)	Sooner by
Interactive screen up (HMI)	~48 s	~32 s	~16 s
Touch ready	~48 s	~32 s	~16 s
WiFi access point ready	~55 s	~39 s	~16 s
Phone Wi-Fi associated	~62 s	~50 s	~13 s
CarPlay session active	~71 s	~55 s	~16 s

Most of the gap between “screen up” and “CarPlay” is avoidable waiting: the Wi-Fi hardware is ready well before the software lets it start, and on the busy first core it has to wait its turn. The last ~12–16 s before CarPlay is partly the phone’s own Wi-Fi/CarPlay handshake, which the head unit does not control — so that tail varies more boot to boot. Full per-boot ranges and methodology are on /screentune/boot-optimization/.

The ~100 services

The SM starts around 100 userspace services. Many target hardware that is absent or platforms that no longer exist:

• DVD player service — no drive installed.
• TV tuner service — no tuner installed.
• DAB radio service — not offered in North America.
• SiriusXM services — running with or without a subscription.
• Pandora and Stitcher services — integrations since changed or discontinued.
• Diagnostics and telematics — dealer-facing tools running continuously in the background.

Individually none of these dominate the boot. Together they contend for the CPU during the critical first 30 seconds, exactly when the system is most resource-constrained. Live CPU and memory contention during this window is profiled in /internals/runtime-analysis/.

The nav SD card factor

A navigation SD card adds measurable cost, because the SD reader and the WiFi chip share the same internal data bus. With the card present, WiFi firmware loading takes longer — the two devices arbitrate for the bus.

Across 10 boot cycles:

Metric	SD removed	SD inserted
WiFi startup	~9 s	~12 s
Free memory after boot	170–174 MB	109–144 MB

The memory delta is the system caching map data. On 764 MB with no swap, surrendering 30–65 MB to map cache is significant. If you do not use built-in navigation, pulling the card is a free win. Details in /mazda-connect/nav-sd-performance/.

Why it stays this way

The boot configuration has been essentially unchanged since 2014. The original dependencies assumed USB-only CarPlay and WiFi as a low-priority feature serving mostly AHA Radio. When wireless CarPlay arrived by firmware update, it was grafted onto the existing sequence without reworking the dependency graph — so it inherited the screen-then-radios ordering and the defunct AHA Radio gate.

Mazda’s Gen 7 and Gen 8 systems (2024+) use different hardware and software entirely, leaving little incentive to re-optimize a platform out of production. For the millions of Gen 6 cars still on the road, the ordering is what it is unless you rewrite the graph.

The biggest editable factor is not in the dependency graph at all — it is the single-core scheduling described above: rebalancing Wi-Fi and CarPlay bring-up onto the second core is what moves CarPlay ~16–20 s sooner. The avoidable waits in the graph (the AHA Radio gate, the stage_3 gating of BDS, the fixed sleeps, the absent-hardware services) are editable too and add to that result. That is what our boot work targets; see /screentune/boot-optimization/. The Apple-protocol handshake at the tail is not editable from the car. For the owner-facing version of the fix, see /mazda-connect/slow-boot-fix/.