# Migrate to Qualcomm Linux 1.4 or later releases Consider the following key updates and improvements to learn how to migrate from the Qualcomm^®^ Linux^®^ 1.3 release to Qualcomm Linux 1.4 or later releases. Qualcomm Linux 1.4 and later releases have the latest long-term support (LTS) version of Yocto 5.0, known as Yocto `scarthgap`. The generic buffer management (GBM) memory manager and Weston drivers are now upstream, replacing the downstream versions used in 1.3 and earlier releases. If you’re new to Qualcomm Linux and using the latest 1.8 release, there’s no need to migrate your software. For the list of new features, enhancements, and limitations of the latest release, see [Qualcomm Linux 1.8 Release Notes](https://docs.qualcomm.com/bundle/publicresource/topics/80-70029-300/). ## Changes in Yocto The changes in Yocto for the 1.4 and later releases are as follows: - Upgraded the Yocto release from `kirkstone` (v4.0.22) to `scarthgap` (v5.0.15). For the features and enhancements of `scarthgap`, see [Release notes for 5.0 (scarthgap)](https://docs.yoctoproject.org/5.0.15/singleindex.html#release-notes-for-5-0-scarthgap). - Upgraded the GNU Compiler Collection (GCC) compiler to v13.2. To avoid compatibility issues, recompile any prebuilt applications with the latest Qualcomm Linux release. ## Changes in kernel In the 1.6 and later releases, you can control interfaces from a userspace program that runs in the high-level operating system (HLOS) of the Qualcomm Linux software. This control is facilitated through the `qcom,load-firmware` property that’s added to kernel device tree node. Define this property for the interfaces that must be controlled by the HLOS. For more information about the property, see the [Changes in interfaces](https://docs.qualcomm.com/doc/80-70029-150/topic/introduction.html#interfaces). ## Changes in memory manager In the 1.4 and later releases, the upstream [`libgbm` package](https://git.openembedded.org/openembedded-core/tree/meta/recipes-graphics/mesa?h=scarthgap&id=00a662c5e28235fb64348aab4ce9aeb5e7f95d06) for memory management replaces the downstream variant. This change affects the memory formats and GBM functionality across display, graphics, video, and camera modules. For the list of formats supported by the upstream GBM, see the [`mesa` repository](https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gbm/main/gbm.h). ## Changes in partition In the 1.2 and later releases, the Qualcomm Linux targets use bootloader specification `uapi-group` UUIDs instead of partition label names. These UUIDs are fixed. To change the partition labels or UUIDs, and to avoid incompatibility issues, contact Qualcomm. If your device has 1.2 or earlier release and the partition definitions are label-based, switch to UUID-based mapping before upgrading to later releases. For the UUID of each partition entry, see the [Qualcomm Linux 1.8 Release Notes](https://docs.qualcomm.com/bundle/publicresource/topics/80-70029-300/). In the 1.6 release, there’s a change in the partition table for QCS6490 and QCS5430 products that are based on EMMC storage. If you’re upgrading the device software from 1.5 release and the device uses EMMC storage, over-the-air (OTA) migration to 1.6 or later release isn’t supported. ## Changes in real-time subsystem In the 1.6 release, the real-time subsystem (RTSS) module has migrated to FreeRTOS as the operating system. It uses two binaries for the firmware instead of a single binary. These binary images, `sailhyp.elf` and `sailsw1.elf`, are proprietary and are compiled from the FreeRTOS source code. When upgrading from 1.5 to 1.6 or later release, you must reflash the RTSS binaries, as the RTSS firmware in the 1.5 release is incompatible with the application processor images in the 1.6 or later release. The RTSS images of 1.6 or earlier release aren’t compatible with the application processor (main domain) images of the 1.7 or later release. When you’re migrating the device to 1.7 or later release, flash the SAIL images of 1.7 or later release again to ensure that the RTSS images and main domain images belong to the same release version. This is only applicable to IQ-9 and IQ-8 chipsets. For the instructions to flash the RTSS images, see the [Qualcomm Linux Build Guide](https://docs.qualcomm.com/doc/80-70029-254/topic/flash_images.html#flash-sail). ## Changes in display In the 1.4 and later releases, the display stack of the QCS6490 and QCS5430 system-on-chip (SoC) platforms is now upstream, eliminating the need for the proprietary Snapdragon^®^ Display Manager (SDM) backend. The IQ-8275 and IQ-9075 SoC platforms already use an upstream display stack. Due to this migration, some features that depend on the SDM component aren’t available by default. If you need these features, you can switch the display stack to the downstream implementation. To enable these features in 1.4 and later releases, use the information in the following table: |
Feature |
Support in release |
Support in release |
Support in release |
Support in release |
Support in release |
Enable the feature | | --- | --- | --- | --- | --- | --- | --- | |
Feature | 1.4 | 1.5 | 1.6 | 1.7 | 1.8 |
Enable the feature | | Embedded DisplayPort (eDP) support | ✓ | ✓ | ✓ | ✓ | ✕ | Enable the downstream path as described in [Qualcomm Linux Display Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70023-18A/dd.html). | | Type-C over DisplayPort (DP) | ✓ | ✓ | ✓ | ✓ | ✕ | Enable the downstream path as described in [Qualcomm Linux Display Guide - Addendum](https://docs.qualcomm.com/bundle/resource/topics/80-70023-18A/dd.html). | | Prebuild modetest binary | ✓ | ✓ | ✓ | ✓ | ✓ | In the `libdrm_2.4.120.bb` file, enable the `install-test-programs` option. For more information, see [Qualcomm Linux Display Guide](https://docs.qualcomm.com/bundle/publicresource/topics/80-70029-18/samples.html#panel-0-UUNTNjQ5MA==tab$run-drm-modetest). | | | | | | | | | ## Changes in camera In the 1.4 and later releases, the buffer management utility uses the upstream GBM component instead of the downstream component. Therefore, change the Qualcomm Intelligent Multimedia (IM) commands that invoke camera buffer management. The default format for raw buffers is now `memory:GBM`. Don’t specify the memory format in the `gst` commands. **Pipeline example** - The pipeline for the 1.3 release is as follows: gst-launch-1.0 qtiqmmfsrc name=camsrc video_0::type=preview ! video/x-raw\(memory:GBM\),format=NV12,width=1920,height=1080,framerate=30/1,compression=ubwc ! waylandsink fullscreen=true async=true sync=false Copy to clipboard - The pipeline for the 1.4 and later releases is as follows: gst-launch-1.0 -e qtiqmmfsrc name=camsrc video_1::type=preview ! video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1,interlace-mode=progressive,colorimetry=bt601 ! waylandsink fullscreen=true sync=false Copy to clipboard For more information about changes in the plugins, see [Changes in Qualcomm IM SDK](https://docs.qualcomm.com/doc/80-70029-150/topic/introduction.html#qim-sdk). ## Changes in video To manage buffers for video encoding or decoding, the 1.4 and later releases support direct memory access (DMA) Export mode (4), DMA Import mode (5), and Memory Map (MMAP) mode (2). Select the appropriate mode for your specific use case. **Example** When you encode in camera, it already produces DMA buffers. In this case, do the following: > > > - Set the encoder input to DMA Import mode (5). This mode ensures that the camera buffer file descriptor (FD) is used directly, without allocating new buffer at video driver-side and copying the content. > - Set the encoder output to DMA Import mode (5). This mode ensures that the video driver allocates output buffers. The video pipeline for this example is as follows: gst-launch-1.0 -ev qtiqmmfsrc ! video/x-raw,format=NV12,width=1920,height=1080,framerate=30/1 ! v4l2h264enc output-io-mode=5 capture-io-mode=4 ! h264parse ! mp4mux ! filesink location=/opt/cam_enc.mp4 Copy to clipboard In this pipeline, the `output-io-mode` is DMA Import mode (5), indicating input to the encoder, and the `capture-io-mode` is DMA Export mode (4), indicating output to the encoder. ## Changes in audio In the 1.5 and later releases, the audio stack of Qualcomm Linux has migrated from PulseAudio to PipeWire framework. Native audio validation commands now use PipeWire in place of PulseAudio. For more information, see [Qualcomm Linux Audio Guide](https://docs.qualcomm.com/bundle/publicresource/topics/80-70029-16/audio.html). The applications created using Qualcomm IM audio plugins are already compatible with PipeWire. No change is required for those applications. ## Changes in interfaces In the 1.5 and earlier releases, QUP v3 serial engine firmware is loaded using TrustZone, which has fixed protocol assignments and limited flexibility. In the 1.6 and later releases, you can load QUP v3 serial engine firmware using the Linux kernel. This allows QUP to support multiple serial engines. Upgrading only HLOS while retaining an older version of TrustZone (non‑HLOS) isn’t supported. Starting with 1.6 release, firmware updates are managed by HLOS. Therefore, HLOS and TrustZone must be on compatible versions to ensure proper functionality. The parameters in the device tree source include (DTSI) file for loading firmware have changed. For example, `qcom,enable-gsi-dma` and `qcom,load-firmware`. Update the relevant QUP SE node with these parameters. If the SE use case differs from the Qualcomm reference platform, additional DTSI file changes are required. The following table lists the HLOS and TrustZone version compatibility, firmware loading behavior for specific version combinations, and required actions for each scenario. |
Version compatibility |
Version compatibility |
Firmware is loaded by |
Action | | --- | --- | --- | --- | | TrustZone | HLOS |
Firmware is loaded by |
Action | | 1.5 | 1.5 | TrustZone | No changes are required. | | 1.6 | 1.6 | HLOS | | | 1.6 | 1.5 | TrustZone + HLOS | Qualcomm plans to release the following additional TrustZone binaries:
| | 1.5 | 1.6 | TrustZone + HLOS | No changes are required because firmware is already loaded in TrustZone. HLOS detects the firmware loaded in TrustZone and skips loading it. | | | | | | Note If you have access to the modified `devcfg.mbn` file, you can continue using it. You may choose to load firmware using HLOS. For more information about loading the firmware, see the [Qualcomm Linux Interfaces Guide](https://docs.qualcomm.com/bundle/publicresource/topics/80-70029-8/get-started.html#sub$load_qup_v3_serial_engine_firmware_in_linux_kernel). ## Changes in Qualcomm IM SDK Consider the following changes across releases in Qualcomm IM SDK. ### Changes in 1.6 and later releases In the 1.6 and later releases, a new unified plugin performs the Qualcomm IM SDK postprocessing operations and facilitates the integration of custom AI models. The following table lists the Qualcomm IM SDK plugins for machine learning (ML), highlighting their functions and the support available in different releases. **Table: Qualcomm IM SDK plugins for machine learning (ML)** | Plugin | Functionality | 1.5 and earlier releases | 1.6 and later releases | | --- | --- | --- | --- | | `qtimlvconverter` | Transforms incoming video buffers into neural-network tensors while performing required format conversion and resizing. | Supported | Supported | | `qtimlvclassification` | Performs postprocessing of output tensors for classification use cases. | Supported | Supported but will be deprecated | | `qtimlvdetection` | Performs postprocessing of output tensors for detection use cases. | Supported | Supported but will be deprecated | | `qtimlvsegmentation` | Performs postprocessing of output tensors for pixel-level use cases, such as image segmentation and depth-map. | Supported | Supported but will be deprecated | | `qtimlvpose` | Performs postprocessing of output tensors for pose estimation use cases. | Supported | Supported but will be deprecated | | `qtimlvsuperresolution` | Performs postprocessing of the output tensors for video super resolution use cases. | Supported | Supported but will be deprecated | | `qtimlpostprocess` | Provides a library interface for postprocessing the tensor output of inference plugins. It’s customizable. | Not available | Supported | #### qtimlpostprocess plugin The 1.6 and later releases have `qtimlpostprocess`, a postprocessing plugin that reduces processing time and facilitates custom AI model integration in the Qualcomm IM SDK pipeline. It offers a library interface for postprocessing tensor outputs. You can customize it to meet your specific model requirements. The `qtimlpostprocess` plugin implements the following changes within the Qualcomm IM SDK pipelines: - Replaces the earlier plugins for postprocessing in the Qualcomm IM SDK pipelines. - Retrieves the `constants` directly from the model, eliminating the need to specify them in the command-line configuration. - Aligns with the upgraded post-processing workflow, now standardized to use label files in JSON format. For more information about `qtimlpostprocess` plugin and to add a custom AI model for postprocessing, see the [AI developer workflow](https://docs.qualcomm.com/bundle/publicresource/topics/80-70029-15B/add-postprocessing-support-custom-model.html). **Pipeline example for image classification using LiteRT model** - The pipeline for the 1.5 and earlier releases is as follows: gst-launch-1.0 -e --gst-debug=2 \ filesrc location=/etc/media/video.mp4 ! qtdemux ! queue ! h264parse ! v4l2h264dec capture-io-mode=4 output-io-mode=4 ! video/x-raw,format=NV12 ! queue ! tee name=split \ split. ! queue ! qtivcomposer name=mixer sink_1::position="<30, 30>" sink_1::dimensions="<640, 360>" ! queue ! waylandsink sync=true fullscreen=true \ split. ! queue ! qtimlvconverter ! queue ! qtimltflite delegate=external external-delegate-path=libQnnTFLiteDelegate.so \ external-delegate-options="QNNExternalDelegate,backend_type=htp;" model=/etc/models/resnet101_quantized.tflite ! queue ! \ qtimlvclassification threshold=51.0 results=5 module=mobilenet labels=/etc/labels/classification.labels \ extra-operation=softmax constants="Resnet,q-offsets=<46.0>,q-scales=<0.2186901867389679 >;" ! video/x-raw,format=BGRA,width=640, height=360 ! queue ! mixer. Copy to clipboard - The pipeline for the 1.6 and later releases is as follows: gst-launch-1.0 -e --gst-debug=2 \ filesrc location=/etc/media/video.mp4 ! qtdemux ! queue ! h264parse ! v4l2h264dec capture-io-mode=4 output-io-mode=4 ! video/x-raw,format=NV12 ! queue ! tee name=split \ split. ! queue ! qtivcomposer name=mixer sink_1::position="<30, 30>" sink_1::dimensions="<640, 360>" ! queue ! waylandsink sync=true fullscreen=true \ split. ! queue ! qtimlvconverter ! queue ! qtimltflite delegate=external external-delegate-path=libQnnTFLiteDelegate.so \ external-delegate-options="QNNExternalDelegate,backend_type=htp;" model=/etc/models/resnet101_quantized.tflite ! queue ! \ qtimlpostprocess settings="{\"confidence\": 51.0}" results=5 module=mobilenet-softmax labels=/etc/labels/classification.json ! \ video/x-raw,format=BGRA,width=640, height=360 ! queue ! mixer. Copy to clipboard ### Changes in 1.4 and later releases In the 1.4 and later releases of Qualcomm IM SDK, the behavior of the `waylandsink`, `qtiqmmfsrc`, `v4l2h264dec`, and `v4l2h264enc` plugins has changed due to the upstream migration of the memory manager component. For more details, see [Changes in memory manager](https://docs.qualcomm.com/doc/80-70029-150/topic/introduction.html#memory-manager). To reflect the changes in the Qualcomm IM SDK plugins in 1.4 and later releases and the upstream GBM alignment, update the sample applications as follows. #### waylandsink plugin Earlier versions of the Qualcomm IM SDK used a downstream version of the `waylandsink` plugin, which included `x,y,width,height` coordinates as extra arguments. In later releases, this functionality isn’t available due to the switch to the upstream `waylandsink` plugin. Instead, use the `qtivcomposer` plugin for this functionality. The plugin changes and the corresponding actions you must take are as follows: | Change | Change | Action | | --- | --- | --- | | 1.3 | 1.4 and later releases | Action | | Has `x,y,width,height` coordinates. | Provides functionality through the `qtivcomposer` plugin. | Use the `qtivcomposer` plugin for composition. | | | | | **Pipeline example** - The pipeline for the 1.3 release is as follows: gst-launch-1.0 -e qtivcomposer name=mixer sink_0::position="<0, 0>" sink_0::dimensions="<1280, 720>" sink_1::position="<590, 310>" sink_1::dimensions="<640, 360>" mixer. ! queue ! waylandsink enable-last-sample=false sync=true fullscreen=true filesrc location=/opt/mux1.mp4 ! qtdemux ! queue ! h264parse ! v4l2h264dec capture-io-mode=5 output-io-mode=5 ! mixer. filesrc location=/opt/mux1.mp4 ! qtdemux ! queue ! h264parse ! v4l2h264dec capture-io-mode=5 output-io-mode=5 ! mixer. Copy to clipboard - The pipeline for the 1.4 and later releases is as follows: gst-launch-1.0 -e qtivcomposer name=mixer sink_0::position="<0, 0>" sink_0::dimensions="<1280, 720>" sink_1::position="<590, 310>" sink_1::dimensions="<640, 360>" mixer. ! queue ! waylandsink fullscreen=true filesrc location=/opt/mux1.mp4 ! qtdemux ! queue ! h264parse ! v4l2h264dec capture-io-mode=4 output-io-mode=4 ! video/x-raw, format=NV12 ! mixer. filesrc location=/opt/mux1.mp4 ! qtdemux ! queue ! h264parse ! v4l2h264dec capture-io-mode=4 output-io-mode=4 ! video/x-raw, format=NV12 ! mixer. Copy to clipboard #### qtiqmmfsrc plugin In the 1.4 and later releases, the `qtiqmmfsrc` plugin doesn’t support the compression field for universal bandwidth compressed (UBWC) NV12. Instead, use the new format specifically designed for UBWC compressed NV12 images. The plugin changes and the corresponding actions you must take are as follows: | Change | Change | Action | | --- | --- | --- | | 1.3 | 1.4 and later releases | Action | | `format=NV12`


`compression=ubwc` | Added `format=NV12_Q08C` | | | | | | **Pipeline example** - The pipeline for the 1.3 release is as follows: gst-launch-1.0 qtiqmmfsrc name=camsrc video_0::type=preview ! video/x-raw\(memory:GBM\),format=NV12,width=1920,height=1080,framerate=30/1,compression=ubwc ! v4l2h264enc output-io-mode=5 capture-io-mode=5 ! h264parse ! filesink location=/opt/video.h264 Copy to clipboard - The pipeline for the 1.4 and later releases is as follows: gst-launch-1.0 -ev qtiqmmfsrc name=camsrc video_0::type=preview ! video/x-raw,format=NV12_Q08C,width=1920,height=1080,framerate=30/1 ! queue ! v4l2h264enc output-io-mode=5 capture-io-mode=4 ! h264parse ! filesink location=/opt/video.h264 Copy to clipboard #### v4l2h264enc and v4l2h264dec plugins In the earlier releases, the GST framework managed the application buffers. In the 1.4 and later releases, the `v4l2` drivers support buffer management internally. To add this enhancement to the driver, do the following: - For applications that use the camera source with the `v4l2h264enc` plugin, change the pipeline configuration from `output-io-mode=5`/ `capture-io-mode=5` to `output-io-mode=5`/ `capture-io-mode=4`. - For applications that use the location of the source file (for example, `filesrc location=/opt/test_video.mp4`) with the `v4l2h264dec` plugin, change the pipeline configuration from `output-io-mode=5`/ `capture-io-mode=5` to `output-io-mode=4`/ `capture-io-mode=4`. The plugin changes and the corresponding actions you must take are as follows: | Use case | Change | Change | Action | | --- | --- | --- | --- | | Use case | 1.3 | 1.4 and later releases | Action | | Video encode | `format=NV12`


`compression=ubwc` | Added `format=NV12_Q08C` | | | Video encode | `output-io-mode=5` and `capture-io-mode=5` | Updated to `output-io-mode=5` and `capture-io-mode=4` | Change the modes to `output-io-mode=5` and `capture-io-mode=4`. | | Video decode | `output-io-mode=5` and `capture-io-mode=5` | | | | | | | | **Pipeline example** - The video decoder pipeline for the 1.3 release is as follows: gst-launch-1.0 -e filesrc location=/opt/mux1.mp4 ! qtdemux ! queue ! h264parse ! v4l2h264dec capture-io-mode=5 output-io-mode=5 ! waylandsink fullscreen=true Copy to clipboard - The video decoder pipeline for the 1.4 and later releases is as follows: gst-launch-1.0 -e filesrc location=/opt/mux1.mp4 ! qtdemux ! queue ! h264parse ! v4l2h264dec capture-io-mode=4 output-io-mode=4 ! video/x-raw,format=NV12 ! waylandsink fullscreen=true Copy to clipboard - The video encoder pipeline for the 1.3 release is as follows: gst-launch-1.0 -e qtiqmmfsrc name=camsrc video_0::type=preview ! video/x-raw\(memory:GBM\),format=NV12,width=3840,height=2160,framerate=30/1,compression=ubwc,interlace-mode=progressive,colorimetry=bt601 ! queue ! v4l2h264enc capture-io-mode=5 output-io-mode=5 ! queue ! h264parse ! mp4mux ! queue ! filesink location="/opt/mux1.mp4" Copy to clipboard - The video encoder pipeline for the 1.4 and later releases is as follows: gst-launch-1.0 -e qtiqmmfsrc name=camsrc video_0::type=preview ! video/x-raw,format=NV12_Q08C,width=3840,height=2160,framerate=30/1,interlace-mode=progressive,colorimetry=bt601 ! queue ! v4l2h264enc capture-io-mode=4 output-io-mode=5 ! queue ! h264parse ! mp4mux ! queue ! filesink location="/opt/mux1.mp4" Copy to clipboard ## Next steps - To update over-the-air (OTA) for Qualcomm Linux, see [Qualcomm Linux Yocto Guide](https://docs.qualcomm.com/bundle/publicresource/topics/80-70029-27/update_fw_and_os_qualcomm_linux_using_capsule_and_ostree_mechanisms.html). - To learn more about the new features, enhancements, and limitations of the Qualcomm Intelligent Multimedia (IM) SDK, see [Qualcomm Intelligent Multimedia (IM) SDK Release Notes](https://docs.qualcomm.com/bundle/publicresource/topics/80-70029-52/qim-sdk-release-1-8.html). - To learn more about the new features, enhancements, and limitations of the latest release, see [Qualcomm Linux 1.8 Release Notes](https://docs.qualcomm.com/bundle/publicresource/topics/80-70029-300/). Last Published: Mar 27, 2026 [Next Topic References](https://docs.qualcomm.com/bundle/publicresource/80-70029-150/topics/references.md) Source: [https://docs.qualcomm.com/doc/80-70029-150/topic/introduction.html](https://docs.qualcomm.com/doc/80-70029-150/topic/introduction.html)