> ## 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. # From an Ubuntu EVK demo to a customer-maintained Yocto-based system with QLI (Part 7 of 7) > Move from a fast Ubuntu EVK demonstration to a customer-maintained Yocto-based product software candidate using QLI resources.
← Previous: Part 6
Ubuntu is a fast path to “it runs.” Qualcomm Linux (QLI) is a Yocto-based embedded Linux distribution for Qualcomm hardware. Its reference distributions, metadata layers, recipes, and example code can help a customer build and maintain its own device software. That distinction matters. Ubuntu gives developers a short route to SSH, `apt`, `pip`, Python scripts, AI Hub downloads, LiteRT tests, GenieX, and quick iteration on a Dragonwing EVK. A team that chooses a Yocto-based system takes on a different kind of work: ```text theme={null} same model same app behavior same validation gates more controlled OS/BSP/runtime/update story ``` This post describes one possible transition from standard Ubuntu to a Yocto-based system using QLI. It does **not** present QLI as the only production path, a finished customer product image, or software that Qualcomm operates and maintains on a customer’s behalf. Qualcomm maintains parts of the platform, including Qualcomm-specific kernel and hardware-enablement work, but the customer remains responsible for selecting, adapting, integrating, validating, securing, updating, and maintaining its resulting product software. This post is not a replacement for the Qualcomm Linux setup docs. Use the official Dragonwing Linux pages for flashing, board setup, software updates, and device-specific details: * [Qualcomm Linux overview](/qualcomm-linux-qli) * [IQ-9075 EVK device overview](/Linux/devices/iq9075-evk/device-overview) * [IQ-8275 EVK device overview](/Linux/devices/iq8275-evk/device-overview) The migration question here is narrower: after the Ubuntu EVK demo works, what has to be revalidated when moving to a customer-maintained Yocto-based system built with QLI resources? In the running case study, this is the same smart-camera bundle from Post 6 adapted from an EVK demo into a versioned customer image. Before you start: ```text theme={null} [ ] Ubuntu EVK demo passes functional validation [ ] model/app bundle is versioned [ ] customer’s OS strategy selected: remain on Ubuntu, use QLI resources, or another supported path [ ] QLI/reference components and their licenses/versions reviewed [ ] customer-owned Yocto layers, image, and build are versioned [ ] QAIRT/QNN, GenieX, LiteRT, and plugin versions recorded [ ] target SoC/HTP architecture recorded [ ] sustained latency/FPS/power/thermal gates defined [ ] update and rollback path identified ``` *** ## The two milestones A Qualcomm migration has two different success milestones. ```text theme={null} Milestone 1: It runs on a Dragonwing EVK - often easiest on Ubuntu - fast developer iteration - known-good AI Hub / LiteRT / QNN / GenieX tests - model and app behavior proven Milestone 2: The customer has a maintainable product-software candidate - a customer-owned Yocto/QLI build and BSP alignment - pinned runtime packages - service management - power, thermal, update, and security plan - documented ownership for patches, compliance, and field maintenance ``` The common mistake is treating Milestone 1 as Milestone 2. A demo proves feasibility; a customer-maintained software candidate requires repeatable builds, validation, security processes, and an explicit maintenance owner. QLI reference code does not transfer those responsibilities to Qualcomm. *** ## Why Ubuntu is useful early Ubuntu is a strong Day 0 and development environment because it optimizes for developer speed: ```text theme={null} familiar shell large package ecosystem fast Python iteration simple `pip` / `apt` workflows container-friendly tooling quick AI Hub and GenieX experiments ``` That is exactly what you want when the open questions are: ```text theme={null} Can the model export cleanly? Can the runtime load the artifact? Does HTP acceleration work? Does the app still produce the right output? What latency and power ballpark are we in? ``` For prototypes, lab demos, internal tools, and evaluation, Ubuntu may be the right place to stay for a while. *** ## Why a customer might choose QLI resources QLI is a Yocto-based embedded Linux distribution for Qualcomm hardware. The Dragonwing docs describe a curated stack and provide reference distributions, layers, recipes, setup guidance, and hardware enablement for areas such as AI, GPU, DSP, camera, and multimedia. The documentation calls QLI production-oriented; that describes its design goal, not a transfer of product ownership or maintenance responsibility from the customer to Qualcomm. That can help a customer assemble a product-software candidate: | Need | Why QLI helps | | -------------------- | ------------------------------------------------------------------------ | | BSP alignment | The OS, kernel, drivers, firmware, and userspace are built together | | Smaller surface | Product image can carry fewer development packages | | Long-term control | Yocto/OpenEmbedded layers and recipes fit embedded product maintenance | | Hardware integration | Camera, multimedia, AI, GPU, DSP, and firmware paths are coordinated | | Manufacturing | Image creation, flashing, provisioning, and recovery can be standardized | | Updates | Product update and rollback strategy can be designed around the OS image | The point is not that Ubuntu is “wrong,” and QLI is not a mandatory destination. The customer may remain on Ubuntu, build with QLI, or choose another OS strategy appropriate for its hardware and product. The decision depends on the customer’s requirements, maintenance model, security process, compliance obligations, and support arrangements. *** ## What should be proven before moving Moving too early makes every problem look like an OS problem. Moving too late lets prototype assumptions leak into the product. A good transition point is when these are true on the EVK: ```text theme={null} [ ] source model recovered or selected from AI Hub [ ] migration fit check completed: camera count, resolution/FPS, memory, model size, codec/display, power, OS constraints [ ] ONNX/source baseline validated [ ] Qualcomm runtime path chosen [ ] known-good artifact runs on HTP/NPU where expected [ ] preprocessing and postprocessing are explicit [ ] app-level metric passes on sample data [ ] latency/FPS/power ballpark is acceptable [ ] deployment bundle shape is known ``` At that point, the migration question changes from “can this run?” to “can this run repeatedly on product software?” *** ## What changes during the move The app should not change much. The environment around it will. | Area | Ubuntu EVK demo | Customer-maintained Yocto/QLI candidate | | ----------------- | ------------------------------ | ----------------------------------------------------------------------------------- | | Package install | `apt`, `pip`, manual downloads | image recipes, pinned packages, controlled filesystem | | Runtime artifacts | copied by hand during testing | versioned bundle or image component | | Service start | shell script or terminal | supervised service | | Logs | terminal output | persistent logs with rotation/export | | Camera/media | demo pipeline | product camera/display/encode path | | Updates | reflashing or manual copy | planned OTA/update/rollback path | | Security | developer convenience | least privilege, locked-down access, signed/reproducible artifacts where applicable | | Validation | smoke tests | sustained and repeatable gates | The safest approach is to keep the app contract stable while the OS changes. *** ## Revalidate runtime packages and artifacts AI runtime artifacts are tied to more than the model. Record the exact matrix: ```text theme={null} SoC HTP architecture OS image BSP version QAIRT/QNN SDK version runtime library versions GenieX version, if used AI Hub job/model version, if used model precision context length, for GenAI ``` Rebuild or at least revalidate when any of these change: ```text theme={null} Ubuntu -> QLI BSP update QAIRT/QNN SDK update target SoC change model checkpoint change precision change backend change GenieX runtime change ``` For QNN/QAIRT context binaries, assume target sensitivity. The safer practice is to regenerate and validate for the customer’s selected OS/BSP/runtime combination instead of debugging a stale binary for two days. The customer owns that rebuild and validation process. *** ## Turn the demo into a bundle On Ubuntu, a demo might live in a home directory: ```text theme={null} ~/models ~/scripts ~/venv ~/demo.sh ``` For QLI, make the runtime bundle explicit: ```text theme={null} /opt/edge-ai-app/ bin/ app healthcheck models/ detector.bin llm_bundle/ config/ pipeline.json preprocessing.json postprocessing.json thresholds.json labels/ classes.json lib/ app-specific shared libraries manifest.json ``` Example manifest fields: ```json theme={null} { "app_version": "0.3.0", "target_soc": "QCS9075", "os": "Qualcomm Linux", "model_source": "best.pt sha256:...", "onnx_export": "model.onnx sha256:...", "runtime": "QNN/HTP", "precision": "a8w8", "qairt_sdk": "2.x", "ai_hub_job": "optional-job-id", "validation_set": "validation-v4", "expected_metric": "mAP >= 0.92" } ``` That manifest is boring on purpose. When a field issue appears, boring is excellent. *** ## Make it a service A terminal command is fine for Day 0. A product needs a process model. A minimal service contract: ```text theme={null} starts on boot waits for camera/network/model storage if needed runs as a non-root user when practical restarts on crash writes useful logs exposes a health check fails loudly when model/runtime versions mismatch ``` A small `systemd` shape might look like: ```ini theme={null} [Unit] Description=Edge AI application After=network-online.target Wants=network-online.target [Service] Type=simple WorkingDirectory=/opt/edge-ai-app EnvironmentFile=/opt/edge-ai-app/config/app.env ExecStart=/opt/edge-ai-app/bin/app --config /opt/edge-ai-app/config/pipeline.json Restart=on-failure RestartSec=2 [Install] WantedBy=multi-user.target ``` Keep the service wrapper thin. The app should own health and clear error messages; the supervisor should own restart policy. *** ## Re-run the Day 0 checks on the QLI-based image From Post 2, carry forward the same sanity checks: ```text theme={null} [ ] device is reachable [ ] expected OS image is running [ ] QNN tools are visible [ ] HTP validation passes when available [ ] AI Hub/LiteRT/QNN known-good model runs [ ] GenieX path runs if LLM/VLM serving is part of the product [ ] custom model artifact runs [ ] app-level metric passes ``` This avoids a common trap: debugging the custom app before proving the base runtime on the new OS image. *** ## Sustained validation beats peak numbers Product validation should include the boring run, not just the exciting benchmark. Run the app long enough to catch: ```text theme={null} thermal throttling memory growth file descriptor leaks camera disconnects network drops clock drift log spam watchdog loops update failures ``` Suggested gates: | Gate | Example | | ---------- | ------------------------------------------------------ | | Functional | Same output on fixed test set | | Accuracy | Same product metric as Ubuntu baseline | | Latency | p50/p95/p99 under real camera load | | Throughput | Sustained FPS or tokens/sec | | Memory | Stable RSS over long run | | Power | Average and peak under real workload | | Thermal | No unacceptable throttling over run length | | Recovery | App recovers from camera/network/model-service restart | Peak FPS is useful. Sustained behavior is what ships. *** ## Plan update and rollback early If the product contains AI, we recommend planning for updates early. Models change. Thresholds change. Runtime packages change. Security fixes happen. Define what can update independently: ```text theme={null} OS image AI runtime packages model artifacts app binary configuration labels/tokenizer/assets ``` Then define rollback triggers: ```text theme={null} service fails to start health check fails model/runtime manifest mismatch latency or memory gate fails camera pipeline fails user- or fleet-level canary fails ``` A customer-maintained Yocto/QLI system can give the team a more controlled foundation for this kind of product update story than a loose development image, provided the customer owns and operates the build, security, and update process. Security and update details do not need to be elaborate in the first product candidate, but they should be explicit. Regulations such as the EU Cyber Resilience Act can impose lifecycle, vulnerability-handling, and update obligations on products with digital elements. The customer’s legal and security teams must determine which requirements apply and make sure the product organization—not an unmodified reference distribution—is assigned responsibility for meeting them. ```text theme={null} [ ] image provenance and signing posture recorded [ ] secure boot / boot-chain requirements understood [ ] device identity and API secrets kept out of the app bundle [ ] model/config rollback uses the same health gates as app rollback [ ] debug SSH, default passwords, and developer packages removed or controlled [ ] logs preserve enough evidence without leaking sensitive inputs ``` *** ## Customer-maintained system checklist Before a demo becomes a product candidate: ```text theme={null} [ ] customer’s OS strategy selected: remain on Ubuntu, use QLI resources, or another supported path [ ] QLI/reference components and their licenses/versions reviewed [ ] customer-owned Yocto layers, image, and build are versioned [ ] flashing/provisioning path documented from official Dragonwing docs [ ] QNN/QAIRT runtime versions pinned [ ] target SoC and HTP architecture confirmed [ ] model artifacts rebuilt or revalidated for target OS/BSP [ ] GenieX version pinned if used [ ] deployment bundle manifest created [ ] app runs as a supervised service [ ] logs and health checks available [ ] camera/media path validated on product hardware [ ] latency/FPS/power measured under sustained workload [ ] thermal behavior validated [ ] update and rollback path defined [ ] manufacturing/support notes captured ``` *** ## Migration ledger for the smart-camera case study Close the migration by recording what each Jetson piece became on Dragonwing: | Jetson piece | Dragonwing piece | | ------------------------------- | ----------------------------------------------------------------- | | `best.engine` TensorRT artifact | QNN/QAIRT context binary such as `best_ctx.bin` | | TensorRT INT8 calibration cache | Qualcomm calibration set plus QNN/AIMET quantization flow | | CUDA preprocessing | IM SDK / `qtimlvconverter` / shared preprocessing contract | | DeepStream `nvinfer` | `qtimlqnn` or `qtimltflite` with QNN delegate | | DeepStream metadata | IM SDK metadata plus `qtimetamux` | | CUDA or DeepStream overlay | `qtivoverlay` / display or encode path | | Local LLM sidecar | GenieX local server when the app uses an OpenAI-compatible API | | JetPack image or container | customer-maintained Yocto/QLI image plus versioned runtime bundle | Measurement status should be explicit. If the lab run is not done, say so instead of implying results: | Metric | Jetson baseline | Dragonwing result | Status | | ------------------------- | --------------- | ----------------- | --------------- | | Accuracy / product metric | TBD | TBD | pending lab run | | Latency / FPS | TBD | TBD | pending lab run | | Power / thermal | TBD | TBD | pending lab run | | Sustained run length | TBD | TBD | pending lab run | *** ## Takeaway An Ubuntu EVK demo is a useful first milestone. It proves the model, runtime, and application shape quickly without predetermining the customer’s final OS strategy. If the customer chooses QLI, its distribution, layers, recipes, and reference material can support this transition, but they do not turn a demo into a product automatically. The customer’s engineering organization must turn those inputs into a controlled product candidate: a versioned OS, pinned runtimes, reproducible bundles, service management, sustained validation, and an update story. Keep the application contract stable, rebuild or revalidate target-sensitive artifacts, and make every version visible. Most importantly, assign ownership for OS maintenance, vulnerability response, updates, rollback, and applicable regulatory/compliance work. That is the path from “it runs” to a customer-maintained product candidate.