# Qualcomm Linux System Software Architecture
Qualcomm^®^ Linux^®^ is a Qualcomm‑provided, upstream‑aligned Linux software stack optimized for Qualcomm SoCs. It is not a standalone Linux distribution. Instead, it provides a unified and modular Linux platform that simplifies building, deploying, and maintaining secure, production‑ready Linux solutions across multiple Qualcomm system-on-chips (SoC).
Qualcomm® Linux provides the following capabilities:
- A single Linux platform that supports multiple Qualcomm SoCs
- Integrated AI, multimedia, and connectivity enablement
- Alignment with upstream Linux kernels, combined with commercial stability
- Standards‑based boot, security, and device management
- A virtualization‑ready architecture
- Standards‑based, open interfaces that support scalability and long‑term maintainability
- Platform‑level power and performance optimization that uses upstream Linux mechanisms with Qualcomm enhancements
- Overlay‑based extensibility that enables Qualcomm software additions without rebuilding the operating system
Together, these capabilities provide an upstream‑aligned Linux software stack with optional Qualcomm enhancements. This approach helps customers scale solutions across products and generations while reducing software re‑engineering effort.
**Software stack overview**
Qualcomm Linux is currently supported on [QCS5430](https://www.qualcomm.com/internet-of-things/products/q5-series/qcs5430), [QCS6490](https://www.qualcomm.com/internet-of-things/products/q6-series/qcs6490), [IQ-8275](https://www.qualcomm.com/products/internet-of-things/industrial/industrial-automation/iq8-series/iq-8275), [IQ-9075](https://www.qualcomm.com/products/internet-of-things/industrial/industrial-automation/iq9-series/iq-9075), and [IQ-615](https://www.qualcomm.com/products/internet-of-things/industrial-processors/iq6-series/iq-615) system-on-chip (SoC) platforms. The software stack uses upstream components across the stack and can also include installable downstream Qualcomm proprietary software packages.
The stack includes:
- A Unified Extensible Firmware Interface (UEFI) bootloader
- A Linux long‑term support (LTS) kernel with a small number of patches that are being upstreamed
- Upstream aligned user-space stacks
- Installable software packages (Overlays) for custom features
**Figure : System software architecture overview**
**Qualcomm Linux overlays**
Qualcomm^®^ Linux^®^ overlays are value-added packages that can be cleanly applied on top of the upstream software. Qualcomm Linux overlays consist of source code or prebuilt binaries for technology components such as audio, camera, graphics, and video.
An overlay is an add-on that layers Qualcomm technology (driver and user space, and in some cases a device tree overlay) on top of an upstream-aligned stack without modifying it. This approach enables switching between upstream and downstream (Qualcomm) implementations on a per technology basis.
Qualcomm Linux overlays enable developers to choose between upstream and overlay stacks for experimentation and feature analysis and to select a combination of overlays that best suit product requirements.
Overlays may include:
- User-space components (user mode driver (UMD), libraries, and tools)
- Kernel components delivered as dynamically loadable kernel modules (DLKMs)
- For some technology areas (notably Camera), an associated device-tree overlay (DTBO)
For more information about overlay configurations and overlay packages, see [overlay documentation](https://docs.qualcomm.com/doc/80-80020-150).
Note
The descriptions in the following sections are for informational purposes only. For a complete list of software features enabled and any known issues, see the [Release Notes](https://docs.qualcomm.com/doc/80-70023-300).
## Display
The Qualcomm® Adreno™ Display Processing Unit (DPU) is a hardware-accelerated image processing engine designed to retrieve pixel data from memory and transmit it to display peripherals through standard display interfaces.
The following figure shows the high-level overview of the display architecture.
**Figure : DPU architecture**
The DPU supports the following image processing capabilities:
- **Composition:** Combines multiple image layers into a single output frame.
- **Scaling:** Upscales or downscales images to match the attached display resolution.
- **Color Format Conversion:** Converts between color formats (for example, YUV to RGB).
- **Color Space Conversion:** Transforms across color spaces such as sRGB, Display P3, and BT.2020.
- **Color Processing:** Adjusts color attributes to improve display quality.
### Supported interfaces
The DPU supports industry-standard display interfaces such as:
- **MIPI DSI** (Mobile Industry Processor Interface -Display Serial Interface): A high-speed serial interface used between a host processor and display panels.
- **DisplayPort:** A digital display interface supporting video, audio, and auxiliary data transmission.
### Display architecture
This section summarizes key components of the Qualcomm Linux display subsystem in hardware and software.
**Display hardware architecture**
The hardware architecture includes components for source and destination processing, layer mixing, compression, and display interfaces.
**Figure : DPU hardware architecture block diagram**
The following table lists the components of the display hardware architecture.
| **Component** | **Description** |
| --- | --- |
| Bus interface | Fetches data from memory for processing |
| Source surface processing | Reads RGB and YUV surfaces and performs format conversion and quality improvements. |
| Blending | Blends and mixes source surface together |
| Destination surface processing | Converts, corrects, and adjusts the data based on panel characteristics |
| Compression | Reduces bandwidth and power consumption by sending compressed display buffers to the display |
| Display interface | Generates timings for the connected display peripherals |
**Display software architecture**
The display subsystem consists of Wayland, a display server protocol, and its compositors such as Weston. Wayland uses a client/server model in which client applications interact with the Wayland server.
**Figure : Display software architecture**
The components of the display software architecture are as follows:
**Table : Display software architecture components**
| Component | Description |
| --- | --- |
| Wayland sink | Communicates with Weston subsystem to render output. |
| Wayland compositor (Weston) | Handles composition and rendering at the system level. |
| Direct rendering manager (DRM) backend | Manages DPU hardware resources and selects composition strategies for connected displays. |
| libdrm | Provides APIs for accessing DRM input/output control (IOCTL). |
| DRM/KMS framework | Provides kernel and user-space interfaces (through libdrm) for hardware configuration and acceleration. |
| Adreno DPU driver | Manages pixel data paths to different panel interfaces. |
| Adreno DPU | Hardware engine for display image processing. |
Qualcomm Linux provides display-related APIs through Wayland APIs and libdrm APIs (for interaction with the DRM/KMS framework).
For more information, see:
- [Wayland Client APIs](https://wayland.freedesktop.org/docs/html/apb.html)
- [Wayland Server APIs](https://wayland.freedesktop.org/docs/html/apc.html)
- [libdrm APIs](https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html)
## Audio
The [audio subsystem](https://docs.qualcomm.com/doc/80-80022-16/topic/audio.html) , powered by Low Power AI (LPAI), delivers voice user interface and audio experiences using a dedicated hardware-based AI accelerator.
**Figure : Audio component overview**
The audio system includes:
- **Application processor:** Handles playback, recording, decoding, and post-processing.
- **Low-Power AI (LPAI):** Supports playback, recording, and voice activation (VA) algorithms. LPAI integrates with the Qualcomm® Hexagon™ Processor (QDSP6) and a low-power island (LPI).
- **Audio codec:** Converts audio between analog and digital using an analog-to-digital converter (ADC) and digital-to-analog converter (DAC).
- **Speaker AMP and microphone:** External devices connected using I2S, time-division multiplexing (TDM), or SoundWire.
Qualcomm Linux supports:
- Audio through ALSA System-on-Chip (ASoC)
- AudioReach-based audio using overlays
### OSS (ASoC) audio overview
ASoC is an Advanced Linux Sound Architecture (ALSA) framework for embedded platforms. It enables user-space applications to capture audio and request playback. The implementation is PipeWire-based and supports the GStreamer multimedia framework.
ASoC separates codec and SoC responsibilities to enable reuse across platforms. It supports board-level controls such as amplifier enable, jack detection, and custom routing without requiring changes to codec or platform drivers. ASoC appears as an ALSA sound card to user space, which supports common tools and libraries such as alsa-lib, alsamixer, aplay/arecord, GStreamer, and PipeWire.
### OSS audio architecture
ASoC divides the audio stack into three drivers:
- **Codec Driver**: Defines codec capabilities, audio controls, and dynamic audio power management (DAPM) routing. It is platform-independent.
- **Platform Driver:** Implements direct memory access (DMA) engines, CPU digital audio interface (DAI), and other SoC-specific audio components.
- **Machine Driver:** Board-specific layer that describes CPU-to-codec connections and handles device-specific audio events.
**Figure : OSS audio architecture**
### OSS audio feature support
- **Audio Playback:** Outputs sound through speakers or headphones.
- **Audio Record:** Captures sound from a microphone or other input source.
- **Device Switch (Static):** Routes audio to a selected output device based on predefined settings.
- **Headphone:** Detects when headphones are connected and routes audio for private listening.
### Audio overlay
The overlay audio subsystem supports capture and playback. PipeWire acts as the sound server, enabling audio playback and capture. The captured audio is forwarded to a robot operating system (ROS) 2 node for further processing.
The overlay audio is based on Qualcomm AudioReach™ signal processing framework, including:
- Signal Processing Framework (SPF)
- Audio Processing Manager (APM)
- Qualcomm Audio Calibration Tool (QACT)
The digital signal processor (DSP) handles capture and playback. An audio DSP (aDSP) handles audio workloads, and a compute DSP (cDSP) can be used for compute-intensive use cases and features such as keyword detection.
The following figure shows the high-level overlay audio software architecture.
**Figure : High-level audio software architecture**
**Overlay audio feature support**
- **PCM Audio Playback:** Plays raw, uncompressed audio.
- **PCM Audio Record:** Captures raw, uncompressed audio.
- **Compress Audio Playback:** Plays compressed formats to reduce storage and bandwidth use.
- **Audio Concurrency:** Supports multiple audio activities at the same time (for example, media and notifications).
- **Single Stream Multi Device (SSMD):** Plays one stream across multiple output devices.
- **Multi Stream Multi Device (MSMD):** Plays multiple streams across multiple output devices.
- **Speech Voice Activation (SVA):** Enables wake-word-based activation.
- **Fluence:** Improves voice clarity using noise reduction and echo cancellation.
- **Speaker Protection:** Monitors and controls output to help prevent speaker damage.
- **Device Switch (Static/Dynamic):** Switches output devices based on fixed rules (static) or automatically (dynamic).
### Software components
- **PipeWire:** Routes audio between applications and hardware.
- **Platform Abstraction Layer (PAL):** Higher-level APIs used to access audio hardware and enable audio features.
- **Audio Graph Manager (AGM):** Interfaces for mixer controls and PCM/compressed plug-ins to enable audio features.
- **Audio Reach Graph Service (ARGS):** Creates graphs and packets to configure SPF.
- **Audio Calibration Database (ACDB):** Includes information about various audio use cases such as graphs, module calibration data.
- **Signal Processing Framework (SPF):** Modular framework running on the LPAI DSP to configure and execute processing modules.
- **QACT™ Platform:** PC-based graphical user interface (GUI) tool used to visualize and configure audio graphs and store them in acdb.
For more information, see:
- [Enable Audio Guide](https://docs.qualcomm.com/doc/80-80022-16/topic/enable-audio.html)
- [Customize Audio Use Case](https://docs.qualcomm.com/doc/80-80022-16/topic/customize.html)
- [Troubleshoot Audio](https://docs.qualcomm.com/doc/80-80022-16/topic/troubleshoot.html)
## Video
The [video subsystem](https://docs.qualcomm.com/doc/80-80022-20/topic/video-home-page.html) uses upstream Video4Linux2 (V4L2) interfaces. Applications can use V4L2 APIs to play back or record video.
The following block diagrams illustrate the high-level software architecture for video playback and video recording.
**Figure : High-level video playback software architecture**
**Figure : High level video recording software architecture**
### Software components
- **V4L2 Framework:** Exposes standardized interfaces for video capture, encode, and decode. It receives buffers from applications and manages communication with the VPU driver.
- **Adreno VPU Driver:** Sequences the hardware workflow, manages DMA buffers for kernel-to-hardware communication, and returns encoded or decoded output buffers to the V4L2 framework.
- **Adreno VPU (Hardware):** Performs video encode and decode.
- **Adreno VPU firmware:** Runs on the VPU microcontroller and supports codec interpretation and processing tasks such as:
- Parsing and interpreting codec standards.
- Handling entropy coding/decoding.
- Motion vector calculation.
- Managing hardware pipelines.
- Error handling and resilience.
### Video overlay
The [video subsystem](https://docs.qualcomm.com/doc/80-70023-20) overlay implements standard V4L APIs and call sequence. Any V4L2-based multimedia client such as GStreamer can instantiate video codecs to take advantage of the VPU for video encode and decode. Hardware capabilities are exposed through the QIM SDK and V4L2 APIs. Video processing in Qualcomm-based SDKs is offloaded to video engines to free the CPU and graphics processing unit (GPU) for other operations.
For more information, see:
- [Overlay-video-driver](https://github.com/qualcomm-linux/video-driver)
- [Linux kernel function reference](https://www.kernel.org/doc/html/v4.9/media/uapi/v4l/user-func.html)
- [Video memory-to-memory](https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-mem2mem.html)
- [Sample V4L2 application](https://github.com/quic/v4l-video-test-app)
- [Adreno VPU driver in kernel-video-driver](https://github.com/torvalds/linux/tree/master/drivers/media/platform/qcom/iris)
- [VPU firmware](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qcom/vpu)
## Camera
The [camera subsystem](https://docs.qualcomm.com/doc/80-80022-17/topic/camera-documentation.html) supports raw frame capture through a Video4Linux2 image signal processor (V4L2 ISP) driver. It supports camera sensors using the V4L2 sub-device interface. Applications can use V4L2-based camera applications such as [yavta](https://git.ideasonboard.org/yavta.git) and [libcamera](https://libcamera.org/index.html).
The following figure shows a high-level block diagram of the camera architecture:
**Figure : High level camera architecture**
The camera hardware pipeline consists of the following processing blocks:
- **Front-end:** Receives image sensor data, performs initial image processing and statistics collection, and forwards the output to the Post Image Processing Unit.
- **Snapshot Processing:** Dedicated block for snapshot use cases.
- **Post Image Processing Unit:** Enhances image quality and routes output to display or encoder
### Software components
The following figure shows a high-level block diagram of the camera software components:
**Figure : Camera software architecture overview**
| Component | Description |
| --- | --- |
| Gst camera plugin (qtiqmmfsrc) | GStreamer plugin for Qualcomm’s camera subsystem |
| Camera Core Software | Proprietary camera software providing interfaces for sensor drivers, tuning, and custom nodes. |
| Camera Core Driver | Qualcomm camera subsystem driver in the downstream Linux kernel |
| CAMSS V4L2 driver | Qualcomm camera subsystem driver in the upstream Linux kernel |
### Upstream camera
Upstream camera support uses the CAMSS subsystem, which provides a V4L2 image signal processor (ISP) driver for raw frame capture and supports camera sensors through the V4L2 interface. Upstream applications such as yavta and libcamera‑based camapp are supported.
### Camera overlay
The camera overlay uses CAMX to provide an enhanced ISP and algorithm feature set for improved image quality. The camera subsystem supports the GStreamer multimedia framework and uses the qmmfsrc plug‑in for frame capture. The qmmfsrc plug‑in exposes control APIs and transfers camera control to the camera user mode driver (UMD) through the qmmf‑server. The camera kernel‑mode driver (KMD) programs the hardware after control is transferred from the UMD.
**Figure : Camera overlay overview**
## Graphics
The graphics subsystem adopts an upstream-first architecture with the flexibility to layer proprietary capabilities as needed. It supports both the upstream DRM/Mesa graphics framework and Qualcomm’s optimized Adreno and kernel graphics support layer (KGSL) stack through a modular overlay model.
**Figure : Graphics overview**
### Upstream graphics stack
The graphics subsystem uses the upstream Direct Rendering Manager (DRM) and Mesa frameworks as the open‑source base. DRM provides GPU memory management, command submission, and power management, while Mesa delivers Khronos API implementations such as OpenGL ES and Vulkan.
### Graphics overlay
**Figure : Graphics overview**
The graphics subsystem also supports a Qualcomm‑optimized Adreno and KGSL stack that provides proprietary features and production‑grade performance optimizations. Runtime stack selection is supported through a kernel module parameter that enables switching between DRM and KGSL, while the OpenGL Vendor‑Neutral Dispatch (GLVND) loaders dynamically select between upstream Mesa libraries and proprietary Adreno libraries at runtime.
**Kernel graphics support layer (KGSL)**
The Kernel Graphics Support Layer (KGSL) is the kernel‑mode driver for the Adreno GPU and is responsible for submitting commands from the Adreno user‑mode driver to the GPU and coordinating state management through the graphics management unit (GMU).
### Developer Interfaces
Standard developer APIs include:
>
>
> - OpenGL ES
> - Vulkan
> - OpenCL
## AI/ML
The [AI/ML subsystem](https://docs.qualcomm.com/doc/80-70023-15) supports software development kits (SDKs), APIs, development tools, and third-party frameworks and models such as GStreamer and TensorFlow Lite (TFLite). These components provide access to Qualcomm-specific hardware and software capabilities for AI/ML workloads.
The Qualcomm Neural Processing Engine provides unified APIs and modular, extensible libraries per accelerator. Machine-learning plug-ins support inference using both TFLite and the Qualcomm Neural Processing Engine. Delegates are available to accelerate model inference performance.
Supported video analytics use cases include:
- Single stream inference with a live camera.
- Single stream inference on offline video.
- Single stream live camera TFLite inference streamed over real-time streaming protocol (RTSP).
- Single stream live camera preview with DirectNN inferencing.
- Two stream inference with a live camera.
AI/ML use cases are supported using the upstream SDK and through external delegates. The following diagram provides a high-level overview of AI/ML architecture.
For more information, see:
- [LiteRT framework](https://ai.google.dev/edge/litert)
- [Qualcomm AI Runtime (QAIRT)](https://docs.qualcomm.com/doc/80-63442-10/topic/general_overview.html)
## Qualcomm sensing hub (QSH)
The [Qualcomm sensing hub (QSH)](https://docs.qualcomm.com/doc/80-70023-7/topic/overview.html) supports hardware and software sensors such as accelerometer, gyroscope, and pedometer. It provides a unified event-driven framework for drivers and algorithms and supports the same APIs for both hardware-based and software-based sensors.
Note
QSH is supported on QCS5430 and QCS6490. It is currently not enabled on IQ-8275 and IQ-9075 processors.
The Qualcomm® system-on-chip (SoC) includes an application processor that runs the Linux operating system, a low-power application digital signal processor (aDSP), and additional processing units. The low-power processor runs a real-time operating system (RTOS) and uses the Qualcomm Sensing Hub (QSH) framework to manage sensor data streaming.
The aDSP supports the following QSH operations:
- GPIOs configurable as serial buses: serial peripheral interface (SPI), inter-integrated circuit (I2C), improved I2C (I3C), and universal asynchronous receiver/transmitter (UART).
- Serial buses in low-power mode.
- QSH includes a dedicated local memory, which is known as the island.
The following figure shows an overview of the QSH architecture:
**Figure : QSH overview**
## Wi-Fi
Qualcomm Linux provides [Wi-Fi](https://docs.qualcomm.com/doc/80-80022-14/topic/wifi_landing_page.html) functionality, features, and configurable parameters for application development. Wi-Fi functionality is enabled through the ath11k driver and the chipset-specific firmware.
Supported features include:
- 2.4 GHz, 5 GHz, and 6 GHz Wi-Fi bands
- Peak physical layer (PHY) data rate of 2.9 Gbps, 1K quadrature amplitude modulation (QAM)
- Station (STA) mode and Access Point (AP) mode
**Figure : High-level Wi-Fi software architecture**
## Bluetooth
The Bluetooth® wireless technology [subsystem](https://docs.qualcomm.com/doc/80-80022-13/topic/bt-landing-page.html) includes the BlueZ stack and sample test applications for different use cases.
Supported software and chipsets provide the following two modes of operation:
- Basic Rate/Enhanced Data Rate (BR/EDR)
- Bluetooth Low Energy (BLE)
Qualcomm connectivity chipsets (WCN) comply with the Bluetooth Core specification v5.2.
**Figure : Bluetooth overview**
## Security
The [security subsystem](https://docs.qualcomm.com/doc/80-80022-11/topic/security-home-page.html) includes Qualcomm Trusted Execution Environment (TEE) which provides security services, such as image loading, authentication, cache management, cryptography, logging, and Qualcomm fuse-programmable read-only memory (QFPROM) support for Trust Zone (TZ) secure applications.
TZ forms the core of product security on Qualcomm’s platforms. The TZ facilitates a secure execution environment for most product security features and is built on Arm core TZ technology which uses the Arm core secure execution mode.
Security components include:
- Qualcomm TEE & trusted applications
- Secure boot and QFPROM
- Secure storage
- Secure device debugging
- Debug Security
## Boot
The [boot subsystem](https://docs.qualcomm.com/doc/80-80022-4/topic/landing-page.html) supports systemd-boot UEFI boot manager. When the system resets, the bootloader in the application processor executes in secure ROM. It initializes clocks, CPU caches, and the memory management unit (MMU), and then detects the boot device based on boot option configuration. Boot options vary based on the SoC and may include UFS, eMMC, SPI, among others.
The remaining system and subsystem images are then loaded and authenticated in ROM, IMEM, and DDR based on the cold boot flow.
Additional boot features include:
- Secure boot
- Flexible security key architecture (FSKA)
- Configuration data tables (CDT)
- Emergency download (EDL) mode
- Thermal detection to stop device from booting or rebooting in thermal scenarios
## Hypervisor
Kernel-based Virtual Machine (KVM) is the primary hypervisor for Linux-based virtualization on Qualcomm^®^ Linux^®^ platforms. It uses ARM hardware virtualization extensions to provide CPU and memory isolation while operating within the Linux kernel. This approach enables near-native performance for Virtual Machines (VMs). On supported Qualcomm^®^ Linux^®^ platforms, KVM serves as the main virtualization layer and integrates with the Linux^®^ ecosystem, supporting standard virtualization through Quick Emulator (QEMU) and libvirt.
KVM supports a range of virtualization capabilities across compute, input/output (I/O), and subsystem management. These capabilities include support for multiple concurrent VMs, including mixed real-time (RT) and non-real-time workloads, hardware-assisted CPU and memory virtualization, and Peripheral Component Interconnect Express (PCIe) virtualization with Single Root I/O Virtualization (SR-IOV). KVM also supports real-time optimizations through RT-enabled kernel configurations to meet latency-sensitive workload requirements. Peripheral Image Loader (PIL)-based subsystem management is under development and will be enabled incrementally as part of the KVM feature roadmap.
Virtualization can also be enabled to support standard virtual input/output (VirtIO) devices using the QEMU/KVM architecture, based on SoC capabilities and platform integration (for example, VirtIO console, block, graphics processing unit (GPU), and network devices).
To enable KVM and virtualization features, follow these links:
- [Distribution Configuration](https://docs.qualcomm.com/doc/80-80022-27/topic/meta_qcom_distro.html)
- [Enabling Virtualization](https://docs.qualcomm.com/doc/80-80022-3/topic/virtualization.html)
**Figure : High level hypervisor architecture**
## Kernel
Qualcomm Linux provides a long-term support (LTS) Linux kernel and platform drivers for Qualcomm platforms, including support for multimedia, connectivity, security, and peripherals.
The kernel closely tracks the upstream Linux kernel to maintain compatibility and provide access to the latest features and security updates. Qualcomm builds, tests, and maintains the kernel with a focus on functionality, stability, and hardware-specific optimizations.
This approach delivers robust support for IoT and compute use cases and provides customers with a reliable, efficient kernel optimized for Qualcomm hardware.
## RTSS
The Real-Time Subsystem (RTSS) uses a “system-on-chip-within-a-system-on-chip” architecture to deliver real‑time performance through an independent, integrated design that supports computing, networking, and safety use cases. RTSS supports boot, reset, dump collection, low‑power operation, and real‑time application development for IoT products. RTSS operates as a separate subsystem and supports the Free Real‑Time Operating System (FreeRTOS), which is enabled on IQ‑8275 and IQ‑9075 platforms for customers with access privileges.
For more information, see:
- [Real-Time Subsystem documentation](https://docs.qualcomm.com/doc/80-80022-42/topic/rtss-guide.html)
## Over the air updates (OTA)
Qualcomm Linux 1.0 uses OSTree as the default mechanism for Linux upgrades. OSTree provides a version-controlled, immutable file system that supports atomic upgrades and rollbacks.
Firmware updates are delivered through UEFI capsule updates, which provide a secure and standardized method for updating low-level binaries. Qualcomm Linux 2.0 supports the same update mechanisms as Qualcomm Linux 1.0: OSTree for Linux updates and UEFI capsule updates for firmware. This continuity enables a smooth migration path and supports scalable OTA update management for future QLI releases. When upgrading from Qualcomm Linux 1.0 to 2.0, it is recommended that the OTA upgrade includes both the OSTree repository and the firmware capsule.
For more information, see:
- [OTA updates](https://docs.qualcomm.com/doc/80-80022-27/topic/update_fw_and_os_qualcomm_linux_using_capsule_and_ostree_mechanisms.html)
Last Published: May 14, 2026