Skip to main content
The fastest way to lose a day during a hardware migration is to start with your hardest model. If you are moving from Jetson to Dragonwing, our best practice is to begin with a known-good board and a known-good model before bringing over your production TensorRT app, custom CUDA preprocessing, and hand-tuned detector:
This post is not a replacement for the official board setup docs. It assumes your EVK has already been flashed, brought onto the network, and prepared with the required packages. The goal here is the migration sanity check: prove the platform works before debugging your own model. One more framing point: Ubuntu is a fast path to “it runs.” Qualcomm Linux (QLI) is a Yocto-based embedded Linux distribution whose reference distributions, layers, recipes, and example code can help customers build and maintain their own device software. The examples below use Ubuntu-style commands because they are easy to reproduce on an EVK. The same checkpoints still matter on a QLI-based image: QNN runtime installed, HTP visible, AI Hub artifacts available, known-good model running, and app behavior validated. We will cover the optional Ubuntu-to-customer-maintained Yocto transition later in the series. In the running case study, this is the lab day before porting the Jetson smart-camera app: prove SSH, QNN/HTP, GenieX, and one known-good vision path on Dragonwing first. Before you start:

​
Target device

The same Day 0 pattern applies to a Dragonwing EVK in general. The exact model availability, package names, and performance will vary by board and SoC, so select the right target in AI Hub and use the matching Dragonwing setup page. For the examples in this post, think “Dragonwing EVK” first. This series uses IQ-9075/IQ-8275 for EVK names and IQ-9/IQ-8 as family shorthand. IQ-8 and IQ-9 are concrete examples: Required package docs: Those pages cover flashing, serial console, networking, SSH, display, and package installation for Ubuntu. If your team is using QLI / Qualcomm Linux, use the matching QLI setup flow instead and keep the same validation checkpoints. This article picks up after the EVK is reachable and the required AI runtime packages are installed.

​
Step 1: start from a ready EVK

For this post, assume you already have:
The Dragonwing required package pages install the pieces we care about for this post, including:
Once the EVK is reachable over SSH, collect basic system facts:
This check is worth doing early. A surprising amount of “model debugging” is actually an unexpected image, package set, library path, or board variant.

​
Step 2: verify the AI runtime layer

Before running your own model, verify that the Qualcomm AI runtime pieces from the required package setup are present.
For a deeper HTP sanity check, use the QNN platform validator when it is available in the installed tools:
Expected result: the DSP/HTP backend test passes. If this fails, we recommend pausing model-level debugging until the runtime layer is healthy. It is much cheaper to fix the board/runtime setup before introducing a custom model.

​
Step 3: configure AI Hub access

AI Hub is the easiest source of known-good models and device-specific artifacts. Configure the client from your host or from the device, depending on the workflow you are using. On Ubuntu 24.04, use a virtual environment instead of installing into the system Python:
Then verify that AI Hub can see the device class you care about:
Best practice: use AI Hub’s chipset filter before downloading a model. Pick the target that matches your EVK, for example IQ-8275/QCS8275 for IQ-8 or IQ-9075/QCS9075 for IQ-9. If your network blocks AI Hub downloads, check that early by fetching the exact model artifact you plan to use, then plan an offline copy path if that command fails. Avoid relying on a hard-coded public asset URL; catalog paths and versions change.

​
Step 4: run one known-good LLM path with GenieX

For Day 0 LLM validation, we recommend starting with the GenieX quickstart. GenieX gives you the Qualcomm-facing developer path for local LLM/VLM inference: CLI, Python SDK, Docker on Linux ARM64, and an OpenAI-compatible local server. Under the hood, it can use two runtimes: On Linux ARM64 / Dragonwing, follow the GenieX Linux installation guide. The basic verification checkpoint is:
Then run a Qualcomm AI Hub model through the QAIRT path. Treat the model ID as a known-good example from the current GenieX docs and verify it against the supported-models page for your GenieX release:
Or run a GGUF model through the llama_cpp path, again verifying the exact Hugging Face ID and precision for your release:
For GGUF models, Q4_0 is the usual Day 0 choice for Hexagon NPU support. For application integration, the useful smoke test is the local server:
The server defaults to:
and exposes an OpenAI-compatible /v1/chat/completions API. That matters during migration because many Jetson demos already talk to a local LLM service. If the app can speak OpenAI-compatible HTTP, moving the model host to a Dragonwing EVK can be a service URL change instead of an application rewrite. Raw llama.cpp is still useful for advanced debugging and model experiments, but GenieX should be the first recommendation for this Day 0 LLM path.

​
Step 5: run one known-good vision path

For the first vision run, use the Dragonwing AI Hub or LiteRT examples rather than your custom detector. Recommended starting pages: The AI Hub page uses Lightweight Face Detection as an end-to-end example. The LiteRT page shows the core pattern for using the QNN delegate. A simple LiteRT smoke test is to run an installed quantized model through the QNN delegate with benchmark_model. On the IQ-9075 lab image used for this series, the installed face-detection model lives under /etc/models:
Expected result: delegate creation succeeds and the output includes average inference time and memory statistics. On the lab IQ-9075 image, this ran fully delegated on HTP. If the delegate fails to load, fix the runtime/package setup before touching your custom detector. The important application runtime pattern is this:
A few practical lessons from the Dragonwing AI Hub docs are worth carrying into your own app:
  • Select the model for the correct chipset in AI Hub.
  • Prefer quantized models for NPU execution.
  • Inspect the AI Hub example repository for exact preprocessing and postprocessing.
  • Image layout and scaling are model-specific: LiteRT examples commonly use NHWC, ONNX examples commonly use NCHW.
  • Some models have surprising preprocessing details; use the exact AI Hub example code for that model instead of assuming generic grayscale, RGB, or BGR handling.
This is why a known-good vision example is valuable. It proves the delegate path and reminds you that the model is only part of the application.

​
Step 6: choose the path you will carry forward

After one LLM smoke test and one vision smoke test pass, choose the runtime lane for the next migration step: The goal of Day 0 is not to choose every production detail. It is to prove the board, runtime, and known-good model path before you bring over the Jetson model.

​
What this does and does not prove

This is Qualcomm’s fast onboarding lane, not a claim that every Jetson model runs on Day 0. A supported AI Hub/GenieX/LiteRT artifact can get you to first inference quickly. A custom .pt model still enters the longer Post 3 path: export, operator compatibility, quantization, context generation, deployment, and validation. Keep those two experiences separate when comparing onboarding speed.

​
Day 0 checklist

Before migrating a custom model, make this list boring:
If any item fails, the next best step is usually to fix that layer before porting your own model.

​
Why this avoids overlap with setup docs

The Dragonwing docs already do the board bring-up work:
This post is intentionally lighter than those setup guides. Its role is to explain the migration workflow:
That order keeps the first custom-model migration focused. When your YOLO detector fails later, you will know the board, QNN runtime, AI Hub path, LiteRT delegate, and LLM smoke test were already working.