> ## Documentation Index > Fetch the complete documentation index at: https://dragonwingdocs-staging.qualcomm.com/llms.txt > Use this file to discover all available pages before exploring further. # Benefits of Qualcomm Linux 2.0 over Qualcomm Linux 1.0 Qualcomm Linux 2.0 introduces significant improvements over Qualcomm Linux 1.0 across the build system, layer architecture, kernel, device tree management, and technology stacks. The following table provides a high-level summary of the key benefits and advantages of Qualcomm Linux 2.0 compared to Qualcomm Linux 1.0: **Table: Qualcomm Linux 1.0 vs. Qualcomm Linux 2.0** | **Area** | **Qualcomm Linux 1.0** | **Qualcomm Linux 2.0** | | :- | :- | :- | | Build system | Repo-manifest with manual environment variables (`MACHINE`, `DISTRO`, `QCOM_SELECTED_BSP`) | KAS-based build - single command setup, natively CI/CD ready | | Layer architecture | 4 BSP layers: `meta-qcom`, `meta-qcom-hwe`, `meta-qcom-qim-product-sdk`, and `meta-qcom-realtime` | 1 unified BSP layer: `meta-qcom` | | Image recipes | Override-based (`qcom-base-bsp`, `qcom-custom-bsp`), complex conditional logic | Two explicit, transparent images: `qcom-multimedia-image` and `qcom-multimedia-proprietary-image` | | Kernel | v6.6, split into `linux-qcom-base` and `linux-qcom-custom` kernel trees | v6.18 LTS, single unified `linux-qcom` kernel tree for all images | | Device tree | Concatenated multi-DTB with downstream `addons` fragments | FIT-based multi-DTB, upstream-aligned, no `addons` fragments | | UEFI DTB handling | Custom, platform-specific firmware logic for DTB parsing | Generic FIT parser in UEFI - no firmware changes required to add a new DTB | | Qualcomm value-add components | Baked into image via BitBake overrides | Modular overlays - enable or disable at runtime without rebuilding the image | | OTA upgrade | Supported via OSTree and UEFI capsule; requires manual `uefi_sec` step | Supported via OSTree and UEFI capsule; `uefi_sec` step no longer required | | Containers | Qualcomm-defined container packagegroup | Upstream `packagegroup-container` from `meta-virtualization` | | Graphics | Vendor-specific headers (EGL, OpenGL ES), split DT for DRM and KGSL | GLVND vendor-neutral dispatch, unified DT, upstream Simple On-Demand GPU governor | | Audio | Multiple configuration-specific DT audio node variants | Single unified DT audio node reused across all configurations | ## **1. Simplified and unified build system (KAS-based)** The following table lists the key differences in the build system between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: | **Qualcomm Linux 1.0** | **Qualcomm Linux 2.0** | | :- | :- | | Repo-manifest with manual `setup-environment` and multiple environment variables (`MACHINE`, `DISTRO`, `QCOM_SELECTED_BSP`) | KAS (Configuration Automation System) with simple YAML configuration files | | Multi-step manual setup | Single command: `kas build :` auto-clones, configures, and builds | | Customer defined CI//CD | Natively CI/CD-ready with `kas-container` (Docker support) | **Benefit:** Drastically reduces the number of steps to set up a build environment. Developers and CI/CD pipelines can build with a single command, reducing human error and onboarding time. ## **2. Consolidated and Cleaner Layer Architecture** The following table lists the key differences in the build system between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: | **Qualcomm Linux 1.0** | **Qualcomm Linux 2.0** | | :- | :- | | 4 BSP layers: meta-qcom, meta-qcom-hwe, meta-qcom-qim-product-sdk, meta-qcom-realtime | Single unified BSP layer: meta-qcom | | Scattered recipes across multiple layers | All BSP recipes consolidated in one place | **Benefit:** Fewer layers to manage, fewer inter-layer dependencies to track, and a single source of truth for all BSP recipes. Reduces integration complexity for customers building their own layers. ## **3. Cleaner and More Transparent Image Recipe Organization** The following table lists the key differences in the build system between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: | **Qualcomm Linux 1.0** | **Qualcomm Linux 2.0** | | :- | :- | | qcom-multimedia-image with complex BitBake OVERRIDES (qcom-base-bsp, qcom-custom-bsp, qcom-custom-distro) to conditionally include packages | Two clearly separated images: qcom-multimedia-image (upstream) and qcom-multimedia-proprietary-image (Qualcomm value-add) | | Complex to read code as it requires tracing override logic | Explicit, readable image recipes - no conditional logic based on overrides | **Benefit:** Customers can clearly see what is in each image. No more tracing complex override chains to understand rootfs content. Easier to customize and maintain. ## **4. Upstream-Aligned Kernel and Device Tree (LTS v6.18)** The following table lists the key differences in the build system between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: | **Qualcomm Linux 1.0** | **Qualcomm Linux 2.0** | | :- | :- | | Kernel v6.6, split into linux-qcom-base and linux-qcom-custom (two separate kernel trees) | Single unified kernel linux-qcom\_6.18.bb (LTS v6.18) for all images | | Separate addons device tree fragments (downstream-only) | All device trees upstreamed and aligned to standard bindings - no addons fragments | | Concatenated multi-DTB (custom, order-dependent parsing) | FIT-based multi-DTB (standard, structured, order-independent) | | Build-time DTB overlay merging | Boot-time DTB overlay via FIT - more flexible and hardware-aware | **Benefit:** A single, modern LTS kernel simplifies maintenance. Upstream-aligned device trees mean better community support, easier upstreaming of customer changes, and no need to maintain downstream-only patches. ## **5. Modern FIT-Based DTB and UEFI Improvements** The following table lists the key differences in the build system between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: | **Qualcomm Linux 1.0** | **Qualcomm Linux 2.0** | | :- | :- | | Custom, platform-specific UEFI code for DTB parsing | Generic FIT parser in UEFI - standards-aligned (U-Boot, Linux, UEFI) | | Hard-coded offset logic, order/size-dependent | Node-based selection, size and order-independent | | No native DTB overlay support in UEFI | Native DTB overlay (DTBO) support through FIT | | Adding a new DTB requires firmware awareness and validation | No firmware changes required to add a new DTB | **Benefit:** Adding new hardware variants is significantly easier and doesn't require firmware changes. The FIT-based approach is an industry-standard mechanism, reducing vendor lock-in and improving long-term maintainability. ## **6. Modular Overlay Architecture (New in QLI 2.0)** QLI 2.0 introduces new Overlay system - a key architectural advantage: * Qualcomm value-added components (Audio, Camera, Graphics, Video, Sensors, Vision) are delivered as **modular, loadable overlays**. * Customers can **start with a fully upstream image** (qcom-multimedia-image) and selectively enable Qualcomm technology stacks. * Overlays use **module blacklisting** to cleanly swap upstream drivers for Qualcomm-optimized ones at runtime. * No need to rebuild the entire image to switch between upstream and Qualcomm stacks. **Benefit:** Customers get maximum flexibility - evaluate upstream components first, then layer in Qualcomm-specific optimizations only where needed. This is ideal for product development and reduces time-to-market. ## **7. Seamless OTA Upgrade Path from QLI 1.0** * QLI 2.0 supports the **same OTA mechanisms** as QLI 1.0 (OSTree for Linux + UEFI Capsule for firmware). * Customers can upgrade from QLI 1.0 to QLI 2.0 **over-the-air** without re-flashing. * EFI variables are now stored in the EFI partition directly (no need to run uefi\_sec app manually) **Benefit:** Protects existing field deployments. Customers running QLI 1.0 in production can migrate to QLI 2.0 without physical access to devices. ## **8. Simplified Container and Kubernetes Support** The following table lists the key differences in the build system between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: | **Qualcomm Linux 1.0** | **Qualcomm Linux 2.0** | | :- | :- | | Qualcomm-defined container packagegroup, required compatibility scripts | Upstream packagegroup-container from meta-virtualization - no scripts needed | | Kubernetes via packagegroup-qcom-k8s bundled in multimedia image | Dedicated qcom-container-orchestration-image - decoupled from multimedia image | **Benefit:** Cleaner separation of concerns. Container and orchestration workloads are independent of the multimedia stack, making it easier to build purpose-specific images. ## **9. Improved Graphics Stack (GLVND + Unified DT)** The following table lists the key differences in the build system between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: | **Qualcomm Linux 1.0** | **Qualcomm Linux 2.0** | | :- | :- | | Vendor-specific EGL/GLES headers exported directly | GLVND (OpenGL Vendor-Neutral Dispatch) - vendor-neutral interface | | Separate Base and Custom DTs for DRM and KGSL | Unified device tree compatible with both DRM and KGSL drivers | | Adreno TZ governor for GPU DCVS | Upstream Simple On-Demand governor - better performance efficiency | | Firmware bundled with Adreno recipe | Firmware sourced from standard linux-firmware repository | **Benefit:** GLVND improves application portability and reduces vendor-specific coupling. Unified DT eliminates the need to maintain separate DT workflows. Better GPU performance efficiency with the upstream governor. ## **10. Simplified Audio Stack (AudioReach 2.0)** The following table lists the key differences in the build system between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: | **Qualcomm Linux 1.0** | **Qualcomm Linux 2.0** | | :- | :- | | Multiple configuration-specific DT audio nodes per use case | Single, unified DT audio node reused across all configurations | | AudioReach recipes scattered in meta-qcom-hwe | Dedicated meta-audioreach layer with cleaner recipe naming (audioreach-\*) | | Multiple DT variants required for different audio use cases | One common DT node eliminates redundancy | **Benefit:** Reduced DT complexity, easier audio configuration, and a cleaner separation of audio components into a dedicated community layer. ## **11. Streamlined Camera Integration** The following table lists the key differences in the build system between Qualcomm Linux 1.0 and Qualcomm Linux 2.0: | **Qualcomm Linux 1.0** | **Qualcomm Linux 2.0** | | :- | :- | | Camera DT maintained as separate out-of-tree overlay recipes | Camera DT integrated directly into the in-tree kernel | | Multiple fragmented CamX recipes per SoC | Consolidated CamX recipes per SoC (camxlib-kodiak, camxlib-lemans, etc.) | | Separate cameradtb BitBake target | Camera DT compiled as part of bitbake linux-qcom | | Static Camera Client | DTBO overlay-driven live switch between libcamera and GStreamer pipelines at runtime | | Fragmented CHI-CDK License | Unified + OEM-extensible and now customer can use their own license to distribute | | Gunyah hypervisor only | Industry-standard virtualization with KVM hypervisor + Gunyah | | Manual Camera Pipeline Validation | Yavta pre-loaded in the image for faster pipeline validation | | Private Source Availability | Public Repo | **Benefit:** Camera changes are now part of the mainline kernel tree, reducing the number of separate build steps and making camera integration more maintainable.