AMSS / MPSS: The Modem World

Advanced11 min read

Assumes: 0.1 Anatomy of an SoC, 5.4 Multi-OS Layout

Module Progress0/5 pages mastered

Prerequisites: Module 5 (SoC platform), Module 6 (operating systems) What you’ll learn: AMSS/MPSS modem firmware, telematics and eCall, modem updates, ADAS sensor ecosystem, V2X and automotive 5G.

TL;DR

AMSS (Application Modem SubSystem), now commonly called MPSS (Modem Processor SubSystem), is Qualcomm’s modem firmware. It runs on dedicated modem processor cores inside the SoC, not as a guest VM under QHEE. The modem stack handles the full cellular protocol: LTE, 5G NR, RF control, SIM, and power management on REX RTOS. Your QNX and AAOS VMs talk to it over shared memory + SMD + QMI, never by poking modem registers directly. AMSS is loaded from UFS via PIL/remoteproc at boot. Critical gotcha: the hypervisor manages Kryo VMs; it does not manage the modem. Separate silicon domain, separate crash domain, separate flash step.

You adb shell into Android. You attach to QNX. But when telematics dies, OTA stalls, or eCall fails, you’re debugging a third world that doesn’t show up in ps on either OS. That world is AMSS/MPSS. AMSS is the third OS on your SoC that nobody invites to architecture meetings but everyone depends on.

AMSS vs MPSS: Same Beast, New Name

Qualcomm documentation and build artifacts use both terms. Don’t chase ghosts comparing them.

Term	Full Name	When You’ll See It
AMSS	Application Modem SubSystem	Older docs, partition labels (modem), veteran engineers, crash dumps
MPSS	Modem Processor SubSystem	Current Qualcomm release notes, MPSS build IDs, newer flash packages

MPSS is the same modem stack with updated branding. If someone says “flash AMSS,” they mean the modem firmware image regardless of label.

Not a VM Guest — Dedicated Modem Cores

This is the single most important architectural fact for daily work:

	QNX / AAOS VMs	AMSS / MPSS
Runs on	Kryo CPU cores (virtualized by QHEE)	Dedicated modem subsystem ARM cores + Hexagon DSP
Managed by	QNX Hypervisor (QHEE)	Modem bootloader + REX RTOS scheduler
Visible in	adb shell, QNX pidin, VM configs	QMI clients, QXDM, modem crash dumps (not guest OS process lists)
Memory	Guest-carved DRAM regions	Modem internal RAM + shared memory regions with AP
Update path	Android/QNX OTA partitions	modem_a / modem_b firmware partition (Module 7.3)
Crash effect	VM reboot; other VMs may survive	Modem subsystem restart; telematics/data/eCall drop until recovery

The modem shares the same SoC die as Kryo, Adreno, and Hexagon, but it is not a fourth VM sitting beside QNX and AAOS. Think co-processor, not co-guest.

Mental Model

Your cockpit SoC is an apartment building. QNX and AAOS are tenants on floors managed by the hypervisor landlord — shared rules, separate leases, the landlord can evict one without touching the other. AMSS is the building’s own cellular antenna and switchboard room in the basement — same address, separate staff, separate keys. Tenants don’t walk into the switchboard room; they pick up the phone (QMI) and request a connection. If the switchboard crashes, Spotify might still play (AAOS is fine), but nobody can call outside until the switchboard reboots.

AMSS is a country inside your SoC — own government (RTOS), own language (QMI), own border control (PIL/remoteproc). You need a visa (QMI) to talk to it.

What’s Inside AMSS: REX RTOS and the Protocol Stack

AMSS is not a monolithic blob. It’s a full RTOS environment running a layered cellular stack, with QMI as the AP-facing API:

flowchart TB
    subgraph AP["Application Processor (Kryo)"]
        QNX_VM["QNX VM"]
        AAOS_VM["AAOS VM"]
        QMI_CLIENT["QMI Clients<br/>(TelAF, rild, netmgr)"]
    end

    subgraph SHMEM["Shared Memory + SMD"]
        SMD["Shared Memory Driver<br/>Ring buffers · doorbells"]
    end

    subgraph MODEM["Modem Subsystem (NOT a VM)"]
        QMI_SVC["QMI Services<br/>NAS · WDS · DMS · Voice"]
        STACK["Cellular Protocol Stack<br/>LTE · 5G NR · NAS · RRC"]
        RF["RF / Baseband Control"]
        REX["REX RTOS<br/>Modem scheduler"]
        CORES["Modem ARM Cores + Hexagon"]
    end

    ANT["Cellular Antenna / RF Front-End"]

    QNX_VM --> QMI_CLIENT
    AAOS_VM --> QMI_CLIENT
    QMI_CLIENT <-->|"QMI over SMD"| SMD
    SMD <-->|"Shared memory"| QMI_SVC
    QMI_SVC --> STACK
    STACK --> RF
    RF --> REX
    REX --> CORES
    RF --> ANT

REX RTOS

REX (Real-time Executive) is Qualcomm’s legacy RTOS kernel for the modem subsystem. It predates your AAOS build by decades and has nothing to do with Linux or QNX Neutrino. Modem tasks — layer-2 scheduling, handover decisions, SIM hot-swap handling — run under REX with hard real-time constraints that would be impossible to guarantee inside a Linux guest.

REX is the OS that actually owns the air interface.

The Cellular Stack (LTE / 5G NR)

From bottom to top, the modem firmware implements:

Layer	What It Does	Your Symptom When Broken
PHY / RF	Radio transmission, beamforming, power amps	No signal bars, RF calibration failures
L2 (MAC/RLC/PDCP)	Scheduling, retransmission, ciphering	Throughput collapse, frequent drops
L3 (RRC/NAS)	Registration, handover, attach/detach	“Searching for network,” stuck on 2G
5G NR SA/NSA	New Radio modes, dual-connectivity	5G icon missing, LTE fallback only
IMS / Voice	VoLTE, VoNR, emergency call routing	eCall fails, no voice despite data OK

You don’t debug these layers with logcat. You use QXDM, Diag, and QMI indication traces (Module 7.3).

Think About It

Your eCall test fires but the GPS coordinates are wrong by 500 meters. The Android GPS works fine. Where’s the disconnect?

Reveal Answer

eCall MSD coordinates come from the modem GNSS path — TelAF Location Service → QMI LOC → AMSS — not from Android’s LocationManager. The IVI and telematics stacks often use separate GNSS antennas, RF paths, and fusion logic; a healthy AAOS fix proves nothing about the modem-side location fed into the MSD encoder. Compare fixes side-by-side with TelAF Location vs adb dumpsys location, then pull QXDM LOC/NMEA traces and verify the telematics GNSS antenna, SUPL/XTRA assistance, and dead-reckoning calibration NV — a 500 m offset usually means stale modem-side aiding or a wrong antenna path, not a broken IMS voice session.

How the AP Talks to the Modem: Shared Memory + SMD + QMI

The Application Processor (your Kryo cores running QNX/AAOS) never directly executes modem code or maps modem-internal registers into a guest VM. Communication is strictly structured:

Shared Memory

Qualcomm carves out physically contiguous memory regions accessible to both AP and modem. These hold QMI message buffers, bulk data transfer rings, and logging pipes. The hypervisor configures SMP2P / SMEM tables at boot; you see these in device tree and platform config, not in your Android app code.

SMD (Shared Memory Driver) and GLINK

SMD is the legacy transport layer: ring buffers, interrupt doorbells, channel multiplexing. On newer platforms, GLINK multiplexes logical channels over the same shared-memory fabric with lower overhead. Both ride over physically carved AP↔modem memory regions. Multiple logical channels carry QMI, diagnostic, GPS assistance data, and sometimes audio-related paths. If SMD/GLINK channels fail to come up, every QMI call fails even if the modem firmware image loaded correctly.

QMI (Qualcomm Messaging Interface)

QMI is the protocol: typed request/response/indication messages between AP clients and modem services. Think gRPC for the modem, but binary and service-oriented:

QMI Service	Purpose	Daily Touch
NAS (Network Access)	Registration, signal strength, operator selection	“Why no bars?”
WDS (Wireless Data)	PDP context, data call bring-up	Telematics data session
DMS (Device Management)	IMEI, firmware version, reset	Modem version checks in factory
Voice / IMS	Call setup, eCall routing	Emergency call path
UIM	SIM card access	“No SIM detected”

On AAOS, rild (Radio Interface Layer Daemon) and vendor netmgr talk QMI. On QNX telematics stacks, TelAF wraps QMI in C++ APIs (Module 7.2). You almost never write raw QMI in application code, but you will grep QMI error codes in logs. QMI is the language the AP speaks to the modem; SMD is the transport; shared memory is the wire.

Common Gotcha

Beginner thinks the modem runs on the main CPU as another VM. Reality: AMSS executes on dedicated modem-processor ARM cores (with Hexagon for baseband DSP offload) in a separate baseband subsystem with its own RTOS (REX), boot chain, and firmware — not managed by QHEE. QHEE schedules vCPUs, isolates VM memory, and handles VirtIO. It does not boot, schedule, or recover the modem subsystem. A misconfigured VM layout won’t stop AMSS from loading, but a bad modem flash will kill connectivity while QNX and AAOS boot perfectly. When triaging, ask “AP problem or modem problem?” before diving into Android or QNX logs.

Boot and Load: PIL / remoteproc

AMSS doesn’t execute from UFS directly. The boot sequence:

1. XBL / UEFI on Kryo brings up AP-side boot chain
2. Linux/QNX kernel (or hypervisor + guest kernels) starts on AP
3. PIL (Peripheral Image Loader) / remoteproc framework loads the modem firmware image from the modem_a or modem_b UFS partition into modem subsystem memory
4. Modem cores start executing AMSS; REX scheduler takes over
5. SMD channels establish; QMI services register; AP clients can connect

If PIL fails silently, you get a booted IVI with zero cellular, one of the most common “everything looks fine except no network” factory failures.

Modem Subsystem vs Hexagon DSP — Don't Conflate

Both are “not the CPU” and both load via PIL, but they serve different masters. Hexagon DSP (ADSP/CDSP) runs audio, sensor, and CV offload under FastRPC from QNX/AAOS. Modem subsystem (AMSS/MPSS) runs cellular under QMI from telematics daemons. Flashing adsp fixes voice wake-word; flashing modem fixes LTE attach. Partition names, build IDs, and diagnostic tools are completely separate. Mixing them up in a flash script is a career-limiting move.

Module 0.1 mapped the modem as the SoC’s “post office.” Module 0.3 showed modem_a / modem_b on UFS LUN 1. This page explains what’s actually running in that partition and why it’s invisible to your VM tools. Module 7.2 covers what telematics does with QMI once AMSS is alive. Module 7.3 covers how you flash and update the modem image. Module 8 maps partition names to QFIL programmer steps.

In brief

1. AMSS/MPSS = modem firmware on dedicated cores, not a hypervisor guest.
2. REX RTOS runs the cellular stack (LTE, 5G NR) with real-time guarantees Linux can’t offer.
3. AP ↔ modem communication is shared memory + SMD/GLINK + QMI: structured, never direct register access.
4. PIL/remoteproc loads firmware from modem partitions at boot.
5. Hypervisor isolation does not apply to the modem: separate domain, separate debug, separate flash.

Where You'll See This

When telematics fails but IVI is healthy, your triage split is:

1. Is the modem firmware loaded? Check modem version via TelAF/DMS QMI or factory diagnostic menu. “Unknown” or blank → PIL/load failure.
2. Are SMD/QMI channels up? logcat on AAOS may show rild / netmgr QMI errors. QNX side: telematics daemon init logs.
3. Is it RF or software? No signal in an anechoic chamber with known-good SIM → RF calibration or antenna path. Software attach OK in QXDM but no data on AP → WDS/QMI client bug, not AMSS crash.

When someone asks you to “restart the modem,” that means modem subsystem reset via QMI DMS, not rebooting the AAOS VM. The hypervisor reboot won’t reload a corrupted AMSS image; you need a modem partition reflash (Module 7.3).

Connect the Dots

Module 5 covers the SoC that hosts the modem cores alongside Kryo. Module 7.2 (Telematics) and 7.3 (Modem Updates) continue from here into eCall and modem OTA. Page 10.4 (Software Debug Toolkit) expands modem debug with QXDM workflows, diag port routing, and modem crash dump collection and parsing. Page 10.5 (Debug Decision Tree) includes modem-specific symptoms in the triage flowchart — “no network” maps to AMSS/QXDM as the first tool.

Check Your Understanding

1. What RTOS kernel schedules modem tasks such as handover decisions and layer-2 scheduling inside AMSS/MPSS?

Recall

A. FreeRTOS on the Hexagon ADSPB. QNX NeutrinoC. REX (Real-time Executive)D. Linux (Android kernel)

2. How does the Application Processor communicate with the modem subsystem?

Recall

A. Shared memory transport (SMD/GLINK) carrying QMI messagesB. VirtIO paravirtual device managed by QHEEC. Direct memory-mapped register access from the AAOS kernelD. CAN bus frames forwarded by the QNX gateway

3. Using the apartment building mental model, which statement is correct?

Recall

A. The hypervisor landlord manages AMSS scheduling and memory allocationB. AMSS is a third tenant on the hypervisor floor alongside QNX and AAOS VMsC. If AAOS crashes, the modem subsystem always crashes too due to shared memoryD. AMSS is the switchboard — tenants use QMI instead of entering modem directly

4. AAOS boots normally, cluster works, but cellular data and telematics are completely dead. No modem version reported in diagnostics. Most likely root cause category?

Applied

A. AMSS/MPSS firmware failed to load via PIL — modem subsystem never startedB. QNX hypervisor VM scheduling misconfigurationC. Adreno GPU driver crashD. Android system partition corruption

5. Factory logs show QHEE booted both VMs cleanly, but every QMI client fails with transport errors before any NAS attach attempt. QXDM cannot connect to the modem either. What should you investigate first?

Applied

A. Increase AAOS vCPU affinity mask for the telematics daemon service processB. Disable TrustZone secure world entirely to unblock QMI message transportC. Whether SMD/GLINK channels established after PIL loaded MPSS — IPC transportD. Reflash the AAOS vendor partition to restore the rild radio interface daemon

6. AMSS loads from `modem_a` via PIL after the hypervisor starts guest kernels. Which boot-chain component on the AP side is responsible for loading modem firmware, and why is it outside QHEE's VM management?

Synthesis

Connects to: Module 5 — Boot Chain

A. QHEE EL2 trap handler — schedules modem tasks on spare Kryo vCPUsB. ABL slot switching — same mechanism used for Android A/B OTA updatesC. PIL/remoteproc on AP BSP — modem is a separate peripheral, not a VM guestD. TrustZone secure monitor — loads MPSS firmware into the TEE enclave

Further Reading

• Qualcomm Modem Products — Overview of Snapdragon modem generations (LTE, 5G NR) and the integrated baseband architecture behind AMSS/MPSS.
• Qualcomm Developer Network — Portal for modem documentation, tools (QXDM), and software packages including MPSS build artifacts.
• Qualcomm Automotive Platforms — How modem subsystem, Kryo AP, and Hexagon DSP coexist on a single automotive SoC die.
• Linux Kernel remoteproc Framework — Kernel documentation for PIL/remoteproc loading of modem firmware from UFS partitions at boot.
• 3GPP 5G NR Specifications — Release 15+ NR specs defining the cellular stack layers (PHY, RRC, NAS) running inside MPSS.
• Android Radio Interface Layer (RIL) — How AAOS reaches the modem via rild and vendor RIL HAL — the Android-side counterpart to TelAF on QNX.
• Qualcomm QMI Overview — Background on QMI service architecture (NAS, WDS, DMS, Voice) used for AP-to-modem communication.