# Qualcomm Linux system software architecture
Qualcomm® Linux is a package of software and tools designed for Qualcomm IoT platforms. The following versions are available for application development:
- The *Base* version is an upstream, open-source software stack without Qualcomm proprietary software.
- The *Custom* version includes downstream Qualcomm proprietary software with extra SDKs and improved power performance.
Tab Custom
Tab Base
The Custom version of Qualcomm Linux is currently supported on [QCS5430](https://www.qualcomm.com/products/internet-of-things/industrial/industrial-automation/qcs5430), [QCS6490](https://www.qualcomm.com/products/internet-of-things/industrial/building-enterprise/qcs6490), [IQ-8275](https://www.qualcomm.com/products/internet-of-things/industrial/industrial-automation/iq8-series/iq-8275), and [IQ-9075](https://www.qualcomm.com/products/internet-of-things/industrial/industrial-automation/iq9-series/iq-9075) SoC platforms. The following diagram shows the subsystems and main components in the Custom version.
The rest of the page describes each subsystem in more detail and has links for further exploration.
The Base version of Qualcomm Linux is currently supported on [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) SoC platforms. It uses upstream components for the entire software stack. It includes a UEFI bootloader and the latest Linux LTS kernel (including a few patches that are in process of being upstreamed). Being fully upstream means that this version *doesn’t* support Qualcomm features that are downstream or proprietary.
You can use [upstream gstreamer plugins](https://gstreamer.freedesktop.org/documentation/?gi-language=c) to create applications. To get started, use these [sample apps](https://github.com/quic/sample-apps-for-qualcomm-linux/tree/upstream-gst-sample-apps) to get started. The following diagram shows the subsystems and main components in the Base version.
The rest of the page describes each subsystem in more detail and has links for further exploration.
**Upstream GStreamer**
You can use [upstream gstreamer plugins](https://gstreamer.freedesktop.org/documentation/?gi-language=c) to create application pipelines. You can use the IQ-615 eSDK to create applications for the platform. To get started, see the [upstream-gst-sample-apps](https://github.com/quic/sample-apps-for-qualcomm-linux/tree/upstream-gst-sample-apps) reference applications on GitHub.
Note
The Base version isn’t fully enabled on this release. The descriptions in the following sections are for informational purposes only. For a complete list of software components enabled in the Base version, see the [Release Notes](https://docs.qualcomm.com/doc/80-70029-300).
## Display
Tab Custom
Tab Base
The [display subsystem](https://docs.qualcomm.com/doc/80-70029-18) supports the [Qualcomm® Intelligent Multimedia SDK (IM SDK)](https://docs.qualcomm.com/doc/80-70029-50/topic/overview.html), which is based on the [GStreamer](https://gstreamer.freedesktop.org/) framework and the [Wayland](https://wayland.freedesktop.org/) protocol. These open-source frameworks provide libraries, APIs, and plug-ins to abstract low-level interfaces. The architecture has the following features:
>
>
> - The waylandsink plug-in talks to the Weston subsystem to render the display.
> - The Weston server is a system-level compositor, which takes care of composition and rendering needs and runs as a separate process in the system.
> - libdrm provides APIs for accessing direct rendering manager (DRM) IOCTL.
The [display subsystem](https://docs.qualcomm.com/doc/80-70029-18) supports upstream Wayland/Weston based framework. The direct rendering manager (DRM) backend is the native Weston backend for systems that support the Linux kernel DRM, kernel mode setting (KMS), and evdev input devices. You can use upstream Wayland/Weston based applications to validate and enable display use cases.
For more details see the following:
>
>
> - [Weston documentation](https://wayland.pages.freedesktop.org/weston/)
> - [Driver implementer’s API guide](https://docs.kernel.org/driver-api/index.html)
> - [DRM interfaces](https://docs.kernel.org/gpu/drm-uapi.html)
**User space components**
>
>
>  [GBM](https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/gbm)
>
>
>  [Weston](https://gitlab.freedesktop.org/wayland/weston/-/tree/13.0?ref_type=heads)
**Kernel drivers**
>
>
>  [Display drivers](https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm?h=linux-6.6.y&id=943e0aeece93a9c2329215d02621e634adf6d790)
## Audio
Tab Custom
Tab Base
The [audio subsystem](https://docs.qualcomm.com/doc/80-70029-16) lets a user-space application capture audio and request playback. It’s ALSA-compliant and supports the GStreamer multimedia framework. It also provides an alternate implementation that doesn’t use GStreamer.
It uses PipeWire as the sound server. A GStreamer application can open up a `pwaudiosink` and a `pwaudiosrc` element to render or capture the audio respectively. You can also render out the captured audio to a ROS 2 node for additional processing.
The software audio architecture is [Qualcomm’s AudioReach™ Signal Processing Framework](https://www.qualcomm.com/developer/blog/2024/10/qualcomm-open-sourcing-audio-reach-end-to-end-audio-software). AudioReach comprises the signal processing framework (SPF), the audio processing manager (APM), and the Qualcomm audio calibration tool (QACT) for audio system design and calibration. It’s a complete package of software components, development kits, and tools to design, implement, and validate end-to-end audio use cases across multiple platforms.
The audio DSP (aDSP) is the DSP component responsible for capture and playback. There’s a compute DSP (CDSP) component that you can use for compute applications in general and leverage for specific audio use cases like keyword detection based on the framework support.
The [audio subsystem](https://docs.qualcomm.com/doc/80-70029-16) lets a user-space application capture audio and request playback. It’s PipeWire based and supports the GStreamer multimedia framework.
You can develop a GStreamer application to render or capture the audio respectively. You can also render out the captured audio for additional processing.
The audio DSP (aDSP) is the DSP component responsible for capture and playback. There’s a compute DSP (CDSP) component that you can use for compute applications in general and leverage for specific audio use cases.
 [Audio PAL](https://git.codelinaro.org/clo/le/platform/vendor/qcom/opensource/arpal-lx/-/tree/audio-core.lnx.1.0.r1-rel?ref_type=heads)
 [PipeWire](https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/pulseaudio-plugin/-/tree/audio-algos.lnx.1.0.r1-rel/pipewire-plugin?ref_type=heads)
 [Audio device tree](https://git.codelinaro.org/clo/la/kernel/qcom/-/blob/kernel.qclinux.1.0.r1-rel/arch/arm64/boot/dts/qcom/qcm6490-addons-idp.dts?ref_type=heads)
 [Audio kernel](https://git.codelinaro.org/clo/la/kernel/qcom/-/blob/kernel.qclinux.1.0.r1-rel/sound/soc/qcom/qcm6490.c?ref_type=heads)
## Video
Tab Custom
Tab Base
The [video subsystem](https://docs.qualcomm.com/doc/80-70029-20) supports the GStreamer multimedia framework and various video codecs to take full advantage of the VPU for high-quality, ultra HD video encode and decode. The hardware capabilities of the VPU are most effectively exposed through the QIM SDK and V4L2 APIs. The video encoding and decoding in Qualcomm-based SDKs is completely offloaded to video engines enabling the CPU and GPU to be free for other operations.
The [video subsystem](https://docs.qualcomm.com/doc/80-70029-20) supports video functionality though upstream V4L2 interfaces. You can use the typical V4L2-based interfaces to playback video. For more details about interfaces and sequence flow, see the Linux kernel [function reference](https://www.kernel.org/doc/html/v4.9/media/uapi/v4l/user-func.html) and [video memory-to-memory](https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-mem2mem.html) documentation.
For a sample V4L2 application, see [Github](https://github.com/quic/v4l-video-test-app) for a simple video test application using Linux V4L interfaces.
 [Video kernel driver](https://git.codelinaro.org/clo/la/kernel/qcom/-/tree/0296590122486c15ee6842d0a408c3d5278ab046)
## Camera
Tab Custom
Tab Base
The [camera subsystem](https://docs.qualcomm.com/doc/80-70029-17) supports the GStreamer multimedia framework and uses the qmmfsrc plug-in to, among other things, handle the capture of the camera frames. The qmmfsrc plug-in provides various APIs that lets you control cameras as needed. The qmmfsrc plug-in transfers camera control to the camera user mode driver (UMD) through the qmmf-server (camera daemon). The camera UMD is responsible for controlling the overall camera subsystem, including configuring the camera pipeline according to use cases. It also provides an interface to add camera drivers or customize the camera pipeline. The camera kernel mode driver (KMD) is a collection of Linux kernel drivers for the camera subsystem and is responsible for programming the hardware by taking control from the camera UMD.
 [Camera device tree](https://git.codelinaro.org/clo/le/platform/vendor/opensource/camera-devicetree)
 [Camera kernel driver](https://git.codelinaro.org/clo/le/platform/vendor/opensource/camera-kernel/-/tree/camera-kernel.qclinux.1.0.r1-rel?ref_type=heads)
The [camera subsystem](https://docs.qualcomm.com/doc/80-70029-17) supports the V4L2 interface camera ISP driver for raw frame capture. It supports camera sensors using the V4L2 sub-device interface, so that you can implement or use V4L2-based camera applications such as [yavta](https://git.ideasonboard.org/yavta.git) and [libcamera](https://libcamera.org/index.html).
## Graphics
Tab Custom
Tab Base
The [graphics subsystem](https://docs.qualcomm.com/doc/80-70029-19) supports the GStreamer multimedia framework and uses the GStreamer Wayland plug-in. The GPU uses an OpenGL ES-based ib2C library to provide hardware-accelerated image manipulation, transformation, and color conversion operations. Other features include:
>
>
> - [OpenGL ES](https://www.khronos.org/opengles/): API for developing 2D and 3D graphics on embedded systems. A subset of the OpenGL API.
> - [OpenCL](https://www.khronos.org/opencl/): Open standard for cross-platform parallel programming in heterogeneous systems.
> - [EGL](https://www.khronos.org/egl): Interface between Khronos rendering APIs like OpenGL ES and the underlying native platform window system.
> - [Vulkan](https://www.vulkan.org/): Low-level API and open standard for 3D graphics and computing. Qualcomm Linux supports RGB, UBWC, YUV, and Bayer graphic formats.
The [graphics subsystem](https://docs.qualcomm.com/doc/80-70029-19) is based on the upstream [Mesa graphics stack](https://www.mesa3d.org/) and functional GL/GLES and Vulkan are enabled. For sample graphics applications using the upstream stack, see [gst-sample-applications](https://github.com/quic/sample-apps-for-qualcomm-linux/tree/upstream-gst-sample-apps/gst-video-transform-example).
## AI/ML
Tab Custom
Tab Base
The [AI/ML subsystem](https://docs.qualcomm.com/doc/80-70029-15) supports SDKs, APIs, development tools, and third-party frameworks and models, including GStreamer and TFLite, to provide access to Qualcomm-specific hardware and software capabilities for AI and machine learning. The Qualcomm Neural Processing Engine provides unified APIs and modular/extensible per-accelerator libraries that form a reusable basis for full-stack AI solutions that are usable with Qualcomm’s own frameworks as well as open-source frameworks. With the machine learning plug-ins in the framework, you can use TFLite and the Qualcomm Neural Processing Engine for inferencing. For each of the engines, delegates are enabled to accelerate model inference performance.
The subsystem supports multiple video analytics use cases including:
- Single stream inference with live a camera
- Single stream inference on an offline video
- Single stream live camera TensorFlow Lite inference streamed over real-time streaming protocol (RTSP) source.
- Single stream live camera preview with DirectNN inferencing
- Two stream inference with live camera
AI/ML usecases are supported using the upstream [LiteRT framework](https://ai.google.dev/edge/litert).
## Qualcomm sensing hub (QSH)
Tab Custom
Tab Base
The [Qualcomm sensing hub (QSH)](https://docs.qualcomm.com/doc/80-70029-7/topic/overview.html) supports hardware and software sensors like accelerometer, gyroscope, and pedometer. It offers a unified event-driven framework for drivers and algorithms. It supports the same set of APIs for both the hardware-based and software-based sensors.
QSH is currently supported on QCS5430 and QCS6490. It’s not enabled on IQ-8275 and IQ-9075 processors.
## Wi-Fi
>
>
> Qualcomm Linux provides [Wi-Fi](https://docs.qualcomm.com/doc/80-70029-14) functionality, features, and configurable parameters for developing applications. Wi-Fi functionality is enabled through the ath11k driver along with chipset-specific firmware.
>
>
> The following features are supported:
>
>
>
> >
> >
> > - 2.4 GHz, 5 GHz, and 6 GHz Wi-Fi bands
> > - Peak PHY data rate of 2.9 Gbps, 1 K QAM
> > - Station (STA) mode and Access Point (AP) mode
## Bluetooth
>
>
> The Bluetooth® wireless technology [subsystem](https://docs.qualcomm.com/doc/80-70029-13) includes the BlueZ stack and sample test applications for different user cases.
>
>
> Supported software and chipsets provide the following two modes of operations:
>
>
>
> >
> >
> > - Basic Rate/Enhanced Data Rate (BR/EDR)
> > - Bluetooth Low Energy (BLE)
>
>
>
> Qualcomm connectivity chipsets (WCN) comply with the Bluetooth Core specification v5.2.
## Security
>
>
> The Qualcomm Trusted Execution Environment (TEE) in the [security subsystem](https://docs.qualcomm.com/doc/80-70029-11) provides security services, such as image loading, authentication, cache management, crypto, logging, and Qualcomm fuse-programmable read-only memory (QFPROM) to TrustZone (TZ) secure applications.
>
>
> TZ is the core of product security on Qualcomm’s platforms. The TZ facilitates a secure execution environment for most of the product security features. TZ is built on Arm core TZ technology and relies on the secure execution mode of the Arm core.
>
>
> The product security feature set comprises the following security components:
>
>
>
> >
> >
> > - TZ and secure application
> > - Qualcomm TEE 5.3
> > - Secure boot and QFPROM
> > - HLOS security
> > - Secure storage
> > - Secure device debugging
> > - Secure boot
## Boot
The [boot subsystem](https://docs.qualcomm.com/doc/80-70029-4) of Qualcomm Linux supports systemd-boot UEFI boot manager. When the system resets, the bootloader in the application processor executes in secure ROM and initializes clocks, CPU caches, and the memory management unit (MMU), and then detects the boot device as per the boot option configuration. Boot options include UFS. The remaining system and subsystem images are then loaded and authenticated in ROM, IMEM, and DDR as described in 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
Qualcomm Linux uses Gunyah, a [Type 1 hypervisor](https://docs.qualcomm.com/doc/80-70029-11/topic/features.html#qualcomm-hypervisor) for strong security, performance, and modularity. Independent of any high-level OS kernel, Gunyah runs in a higher CPU privilege level, and doesn’t depend on any lower-privileged OS kernel or code for its core functionality. This design increases its security and can support a much smaller trusted computing base than a Type 2 hypervisor.
Gunyah is designed to support multiple CPU architectures, so its core design ensures architecture independence and portability in non-architecture specific areas. Qualcomm Linux includes the setup tools and scripts, Gunyah core, resource manager, and C runtime environment for the resource manager.
## Kernel space
Qualcomm Linux is a Linux Embedded offering and includes the long-term support (LTS) Linux kernel with the associated kernel platform, multimedia, connectivity, security, and peripheral drivers. Most drivers are pure upstream or in the process of upstreaming, with a few downstream drivers to enable the necessary hardware features.
 [Custom kernel](https://git.codelinaro.org/clo/la/kernel/qcom/-/tree/a91e27bc4e4f363848a25ce732b7294320fbda17)
 [Base kernel](https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/?h=linux-6.6.y&id=0a805b6ea8cda0caa268b396a2e5117f3772d849)
## RTSS
The Real Time Subsystem (RTSS) is designed to deliver real-time performance through an independent, highly integrated architecture that significantly enhances computing, networking, and safety support. RTSS embodies the “SoC-within-a-SoC” concept. For IoT products, the RTSS supports bootup, reset use cases, dump collection, low-power mode, real-time application development, and more. The RTSS operates as a separate subsystem and supports the [Free Real Time Operating System (FreeRTOS)](https://www.freertos.org/?). In the current release, FreeRTOS is enabled on IQ-8275 and IQ-9075 processors in source that customers with access privileges can customize. For a complete set of use cases supported on the RTSS, see the [Real-Time Subsystem documentation](https://docs.qualcomm.com/doc/80-70029-42).
## OTA
Over-the-air (OTA) updates using the OSTree frameworks are supported from QLI GA 1.3. Customers must program the partition layout to ensure migration from QLI GA 1.3 to QLI GA 1.4 through OTA process. Partition layout programming isn’t needed if migrating from QLI GA 1.4 to future releases.
Last Published: Feb 25, 2026