AMSS / MPSS: The Modem World

TL;DR

AMSS (Advanced Mobile Subscriber Software), now commonly called MPSS (Modem Peripheral Subsystem Software), 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 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	Advanced Mobile Subscriber Software	Older docs, partition labels (modem), veteran engineers, crash dumps
MPSS	Modem Peripheral Subsystem Software	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.

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:

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).

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)

SMD is the transport layer: ring buffers, interrupt doorbells, channel multiplexing. Multiple logical channels ride over shared memory: QMI, diagnostic, GPS assistance data, sometimes audio-related paths. If SMD channels fail to come up, every QMI call fails even if the modem firmware image loaded correctly.

QMI (Qualcomm MSM 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

“AMSS is NOT managed by the hypervisor — it’s separate silicon.” 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 + 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).

Check Your Understanding

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

A. QNX hypervisor VM scheduling misconfigurationB. AMSS/MPSS firmware failed to load via PIL — modem subsystem never startedC. Android system partition corruptionD. Adreno GPU driver crash

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

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

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

A. AMSS is a third tenant on the hypervisor floor alongside QNX and AAOSB. AMSS is the building switchboard — tenants use QMI (the phone) instead of entering the modem room directlyC. The hypervisor landlord manages AMSS scheduling and memoryD. If AAOS crashes, the modem subsystem always crashes too