From an Ubuntu EVK demo to a customer-maintained Yocto-based system with QLI (Part 7 of 7)

← 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:

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:

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:

[ ] 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.

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:

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:

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:

[ ] 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:

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:

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:

~/models
~/scripts
~/venv
~/demo.sh

For QLI, make the runtime bundle explicit:

/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:

{
  "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:

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:

[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:

[ ] 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:

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:

OS image
AI runtime packages
model artifacts
app binary
configuration
labels/tokenizer/assets

Then define rollback triggers:

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.

[ ] 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:

[ ] 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.

​The two milestones

​Why Ubuntu is useful early

​Why a customer might choose QLI resources

​What should be proven before moving

​What changes during the move

​Revalidate runtime packages and artifacts

​Turn the demo into a bundle

​Make it a service

​Re-run the Day 0 checks on the QLI-based image

​Sustained validation beats peak numbers

​Plan update and rollback early

​Customer-maintained system checklist

​Migration ledger for the smart-camera case study

​Takeaway