> ## Documentation Index > Fetch the complete documentation index at: https://dragonwingdocs.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` | ## **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.