> ## 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. # Day 0 on Dragonwing: verify the setup, then run your first model (Part 2 of 7) > Verify a Dragonwing EVK, QNN and HTP, GenieX, and a known-good vision model before migrating a custom Jetson workload.
← Previous: Part 1 Next: Part 3 →
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: ```text theme={null} Can I SSH into the board? Can I confirm the expected OS image? Are the required Qualcomm AI packages installed? Can I see the QNN runtime and HTP libraries? Can I run one known-good LLM? Can I run one known-good vision model? ``` 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: ```text theme={null} [ ] Dragonwing EVK flashed and reachable over SSH [ ] required AI/runtime packages installed [ ] QNN/HTP tools available or install path known [ ] AI Hub credentials configured, or offline artifact copy path planned [ ] one known-good LLM and one known-good vision model selected ``` *** ## 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: | Example EVK | SoC | Setup docs | | ----------- | ----------------- | ------------------------------------------------------------------ | | IQ-8 EVK | IQ-8275 / QCS8275 | [Ubuntu setup guide](/Ubuntu/devices/iq8275-evk/set-up-the-device) | | IQ-9 EVK | QCS9075 | [Ubuntu setup guide](/Ubuntu/devices/iq9075-evk/set-up-the-device) | Required package docs: * IQ-8: [Required software packages](/Ubuntu/devices/iq8275-evk/Install_required_software_packages) * IQ-9: [Required software packages](/Ubuntu/devices/iq9075-evk/Install_required_software_packages) 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: ```text theme={null} [ ] Dragonwing EVK flashed [ ] Ubuntu booted [ ] network configured [ ] SSH access working [ ] required software packages installed ``` The Dragonwing required package pages install the pieces we care about for this post, including: ```text theme={null} libqnn-dev qnn-tools tensorflow-lite-qcom-apps GStreamer Qualcomm plugins and sample apps FastCV / multimedia support packages python3-pip and general development utilities ``` Once the EVK is reachable over SSH, collect basic system facts: ```bash theme={null} ssh ubuntu@DEVICE_IP cat /etc/os-release uname -a free -h ``` 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. ```bash theme={null} qnn-net-run --version ls /usr/lib/libQnnHtp*.so ls /usr/lib/libQnnTFLiteDelegate.so ``` For a deeper HTP sanity check, use the QNN platform validator when it is available in the installed tools: ```bash theme={null} qnn-platform-validator --backend dsp --testBackend ``` 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: ```bash theme={null} python3 -m venv ~/qaihub-venv source ~/qaihub-venv/bin/activate pip install qai-hub "qai-hub[torch]" qai-hub configure --api_token YOUR_TOKEN ``` Then verify that AI Hub can see the device class you care about: ```bash theme={null} qai-hub list-devices | grep -E "IQ|QCS" ``` 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](https://geniex.aihub.qualcomm.com/en/get-started/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: | GenieX runtime | Model source | Best for | | -------------- | ----------------------------------- | ----------------------------------------------------------- | | `llama_cpp` | GGUF models from Hugging Face | Broad model coverage, fast experiments, CPU/GPU/NPU options | | `qairt` | Qualcomm AI Hub precompiled bundles | Highest-performance NPU path for supported models | On Linux ARM64 / Dragonwing, follow the [GenieX Linux installation guide](https://geniex.aihub.qualcomm.com/en/run/linux/install). The basic verification checkpoint is: ```bash theme={null} geniex --help ``` 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: ```bash theme={null} geniex infer ai-hub-models/Qwen3-4B ``` Or run a GGUF model through the `llama_cpp` path, again verifying the exact Hugging Face ID and precision for your release: ```bash theme={null} geniex infer unsloth/Qwen3.5-0.8B-GGUF:Q4_0 ``` 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: ```bash theme={null} geniex pull ai-hub-models/Qwen3-4B-Instruct-2507 geniex serve ``` The server defaults to: ```text theme={null} http://127.0.0.1:18181 ``` 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: * [AI Hub workflow](/Ubuntu/ai-workflows/ai-hub) * [LiteRT/TFLite workflow](/Ubuntu/ai-workflows/lite-rt) 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`: ```bash theme={null} benchmark_model \ --graph=/etc/models/face_det_lite_quantized.tflite \ --external_delegate_path=/usr/lib/libQnnTFLiteDelegate.so \ --external_delegate_options='backend_type:htp;library_path:/usr/lib/libQnnHtp.so;skel_library_dir:/usr/lib/rfsa/adsp;htp_precision:0;htp_performance_mode:2' ``` 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: ```python theme={null} from ai_edge_litert.interpreter import Interpreter, load_delegate qnn_delegate = load_delegate( "libQnnTFLiteDelegate.so", options={"backend_type": "htp"}, ) interpreter = Interpreter( model_path="model-w8a8.tflite", experimental_delegates=[qnn_delegate], ) interpreter.allocate_tensors() ``` 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: | Workload | First recommendation | Why | | ---------------------------- | ---------------------------- | ------------------------------------------------------------------------- | | LLM/VLM demo | GenieX with `llama_cpp` | Broad GGUF model coverage and quick iteration | | LLM/VLM production candidate | GenieX with `qairt` | AI Hub precompiled NPU bundles for supported models | | Vision demo | AI Hub + LiteRT/QNN delegate | Smallest Python path to NPU inference | | Custom vision model | ONNX -> QAIRT/QNN pipeline | Needed when your exact model is not already available as a ready artifact | 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: ```text theme={null} [ ] Dragonwing EVK setup completed using the matching Dragonwing docs [ ] required software packages installed [ ] SSH works [ ] OS and kernel version confirmed [ ] QNN tools visible [ ] libQnnHtp.so present [ ] libQnnTFLiteDelegate.so present [ ] HTP platform validation passes when validator is available [ ] AI Hub token configured [ ] AI Hub target device visible [ ] AI Hub artifact download verified or offline copy path planned [ ] GenieX installed or Docker path verified [ ] GenieX known-good LLM runs through `qairt` or `llama_cpp` [ ] GenieX local server considered if the app uses an OpenAI-compatible API [ ] LiteRT/QNN delegate known-good vision model runs on HTP ``` 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: ```text theme={null} flash image connect serial console configure network enable SSH install required packages install or run GenieX run AI Hub / LiteRT examples ``` This post is intentionally lighter than those setup guides. Its role is to explain the migration workflow: ```text theme={null} Use the official setup docs to get the EVK ready. Use Ubuntu when you want the fastest path to a working demo. Use GenieX and known-good vision models to verify the runtime. Only then bring in the Jetson model. If you choose a Yocto-based system, QLI can provide the distribution and reference inputs for the customer’s own integration, build, security, update, and maintenance process. ``` 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.