AMD/Xilinx Kria KV260 Vision AI Starter Kit Setup and Maintenance Guide

Dated: April 15, 2026

Target systems:

• AMD/Xilinx Kria KV260 Vision AI Starter Kit
• AMD Kria K26 SOM on the KV260 carrier card
• Ubuntu 24.04 Server for general evaluation
• Ubuntu 22.04 Desktop when using AMD's validated example applications
• users with only one available host computer:
• Linux host
• Windows host
• Windows with WSL
• macOS host

This guide covers practical setup and maintenance for the Kria KV260 Vision AI Starter Kit, including SD card preparation, first boot, serial access, SSH, Ubuntu setup, firmware considerations, xlnx-config, xmutil, accelerated applications, Smart Camera, BIST, Docker, cameras, storage, backups, and development workflows.

The most important correction from our actual bring-up is simple: Ubuntu 22.04 is the right path for the Smart Camera workflow we actually validated. Ubuntu 24.04 is still useful for general boot and evaluation, but it should not be treated as the primary recommendation when the goal is to reproduce the working SmartCam path we used.

Validated project path:

Board: Kria KV260 Vision AI Starter Kit
Working OS path: Ubuntu 22.04 Kria image for AMD/Xilinx validated apps
Working demo path: KV260 Smart Camera application
Working display target: DisplayPort
Working camera path: MIPI camera input
Working SmartCam directory: /opt/xilinx/kv260-smartcam/bin
Working SmartCam command:
  ./smartcam --mipi --target dp --width 1920 --height 1080 --aitask facedetect --report --screenfps
Observed better task behavior:
  refinedet worked better than facedetect in our testing
Observed issue:
  camera image was rotated 90 degrees clockwise
Observed package/repo issue:
  xilinx-apps PPA sometimes produced a missing-key error for NO_PUBKEY 8FF9183FC8396160
Observed xmutil behavior:
  xmutil often needs sudo
  starter platform can appear as k26-starter-kits / XRT_FLAT before loading app firmware

Recommended practical order:

1. Boot the official Ubuntu 22.04 Kria image.
2. Install and run xlnx-config.sysinit.
3. Fix Xilinx PPA/key/repository issues if apt update fails.
4. Install the needed firmware package, such as xlnx-firmware-kv260-bist or xlnx-firmware-kv260-smartcam.
5. Confirm xmutil sees the platform/application.
6. Load the app firmware with xmutil.
7. Run SmartCam from /opt/xilinx/kv260-smartcam/bin.
8. Use refinedet when facedetect is too weak for practical testing.
9. Set up stable SSH/static IP before doing longer benchmark work.
10. Record FPS, latency, power, thermals, app firmware, Docker image, model, and input/output mode for every run.

For new users evaluating the KV260, AMD recommends starting with Ubuntu 24.04, or Ubuntu 22.04 if you want to run the validated example applications. AMD's KV260 app documentation lists Ubuntu 22.04 as the version with out-of-box validated apps such as Smart Camera, AI Box ReID, Defect Detect, NLP SmartVision, AI Box Distributed ReID, BIST, and DFX; Ubuntu 24.04 is listed for BIST and general boot support. xilinx.github.io

1. Recommended software baseline

Use this baseline for the work we actually performed:

Primary project OS: Ubuntu 22.04 Kria image
Reason: required for AMD/Xilinx validated application demos such as Smart Camera
General evaluation OS: Ubuntu Server 24.04 LTS for Kria
Reason: useful for clean boot, BIST, server-style evaluation, and non-demo experiments
Board: AMD/Xilinx Kria KV260 Vision AI Starter Kit
SOM: Kria K26 SOM
Boot firmware: QSPI on SOM
Runtime OS/application storage: microSD card on carrier card
Primary utility: xmutil
System/demo setup utility: xlnx-config
Application/runtime stack used for SmartCam: XRT, VART/Vitis AI runtime, firmware package, Docker container, SmartCam binary

Practical OS rule:

Use Ubuntu 22.04 when:
- Running Smart Camera
- Running AMD/Xilinx 2022.1 validated applications
- Using xlnx-config app setup flow
- Installing xlnx-firmware-kv260-smartcam
- Matching the Docker/application stack documented for SmartCam

Use Ubuntu 24.04 when:
- You only need a clean modern Ubuntu boot
- You are doing general Linux setup
- You are running supported 24.04 boot/BIST checks
- You are not depending on the 2022.1 SmartCam app stack

Do not treat Ubuntu Core 24 as the default for this guide. Canonical marks Ubuntu Core 24 for Kria as a developer-preview style image, so it is not the right baseline for this SmartCam and accelerator workflow. Ubuntu

2. KV260 boot model

The KV260 does not boot like a normal Raspberry Pi or Jetson Nano. The boot firmware lives in QSPI on the SOM, while the operating system and application files live on the microSD card.

AMD documents the KV260 boot model like this:

QSPI on SOM:
- Boot firmware
- FSBL
- PMU firmware
- Arm Trusted Firmware
- U-Boot
- A/B firmware copies

microSD on carrier:
- Ubuntu or embedded Linux image
- Root filesystem
- Application packages
- Firmware packages
- User files

AMD specifically notes that the SD card image must be written and inserted for the kit to boot Linux successfully, while QSPI contains the board boot chain and redundant A/B firmware images. AMD Documentation AMD Documentation

Do not casually rewrite QSPI firmware when the problem is only at the Linux-image or application layer.

3. Hardware checklist

Prepare:

Kria KV260 Vision AI Starter Kit
12V 3A power supply
microSD card, preferably 32GB or larger
microSD card reader
Ethernet cable
USB cable for UART/JTAG through J4, optional but recommended
DisplayPort or HDMI monitor, optional
USB keyboard and mouse, optional
Host computer for writing the microSD image

The KV260 requires a 12V, 3A adapter and AMD notes that it is not included with the kit. The recommended connector is center-positive with 2.5 mm inner diameter and 5.5 mm outer diameter. The board also ships with an active cooling solution intended to support the full application power budget. AMD Documentation AMD Documentation

4. Important ports and connectors

Useful KV260 connectors:

J4: FTDI USB2.0 UART and JTAG
J5: HDMI output
J6: DisplayPort output
J7: IAS camera connector 0
J8: IAS camera connector 1
J9: Raspberry Pi camera connector
J10: Gigabit Ethernet
J11: microSD card slot
J12: 12V power input
J13: fan power
SW1: firmware update button
SW2: reset button

AMD's KV260 user guide documents J4 as the integrated FTDI UART/JTAG port, J10 as Ethernet, J11 as the microSD boot-device slot, J12 as 12V input, J13 as fan power, and SW1 as the firmware update button. AMD Documentation

5. Choose the correct host path

Use the section matching the only host computer available.

For basic KV260 bring-up, the host mainly needs to write a microSD image and provide serial or SSH access. Native Linux becomes much more important when you move into PetaLinux, BSP, Yocto, Vivado, or Vitis platform work.

6. Linux, Windows, WSL, and macOS image-writing paths

On Linux, write the image with balenaEtcher, Raspberry Pi Imager, GNOME Disks, or dd:

lsblk
sudo umount /dev/sdb*
xz -dk ubuntu-kria-*.img.xz
sudo dd if=ubuntu-kria-*.img of=/dev/sdb bs=4M status=progress conv=fsync
sync
sudo eject /dev/sdb

On Windows, use balenaEtcher, Raspberry Pi Imager, or Win32 Disk Imager. Do not format the card afterward if Windows prompts you.

On Windows with WSL, write the microSD card from Windows-native tools, then use WSL for SSH, Git, rsync, and normal development.

On macOS:

diskutil list
diskutil unmountDisk /dev/diskN
xz -dk ubuntu-kria-*.img.xz
sudo dd if=ubuntu-kria-*.img of=/dev/rdiskN bs=4m status=progress
sync
diskutil eject /dev/diskN

Be careful with dd on both Linux and macOS. Choosing the wrong block device will erase the wrong disk.

7. Insert SD card and boot

Insert the prepared microSD card into J11, then connect:

12V power to J12
Ethernet to J10
Optional USB serial cable to J4
Optional monitor through HDMI or DisplayPort
Optional keyboard and mouse

The Ubuntu 24.04 KV260 boot guide says the board powers on as soon as the power supply is connected, and the default first-login credentials are ubuntu / ubuntu, with a forced password change on first login. xilinx.github.io

8. Serial console setup

Serial console is strongly recommended, especially for accelerated application flows.

Settings:

Baud rate: 115200
Data bits: 8
Stop bits: 1
Parity: none
Flow control: none

Linux:

ls /dev/ttyUSB*
screen /dev/ttyUSB1 115200

macOS:

ls /dev/cu.usbserial*
screen /dev/cu.usbserial-XXXX 115200

Windows:

Use Device Manager to identify the COM port.
Open PuTTY or Tera Term.
Set speed to 115200.

AMD's Smart Camera documentation recommends starting from UART instead of relying entirely on GNOME Desktop, because xmutil desktop_disable can blank the monitor. xilinx.github.io

9. First system checks

After login:

uname -a
lsb_release -a
df -h
lsblk -f
ip addr
which xmutil
xmutil --help
sudo xmutil listapps

On Ubuntu 22.04 Kria images, xmutil is provided as a pre-installed Debian package, while xlnx-config is distributed as a snap for higher-level system and demo setup. Xilinx Wiki

10. Update the system

For either Ubuntu 22.04 or 24.04:

sudo apt update
sudo apt full-upgrade -y
sudo apt autoremove --purge -y

Reboot if kernel, firmware, or system packages changed:

sudo reboot

For Ubuntu 22.04 demo workflows, AMD's setup instructions note that xlnx-config.sysinit also adds Xilinx-specific repositories, handles package updates, and may need to wait for unattended upgrades to finish. Xilinx Wiki

11. Install xlnx-config

For Ubuntu 22.04 validated-app setup:

sudo snap install xlnx-config --classic --channel=2.x
xlnx-config.sysinit

If apt locks are blocking the flow:

ps aux | grep -E "apt|dpkg|unattended"

AMD's Ubuntu 22.04 setup page says xlnx-config is the main configuration utility and that xlnx-config.sysinit adds Xilinx-specific repositories such as ubuntu-xilinx/updates and xilinx-apps/ppa. Xilinx Wiki

12. Xilinx repository and GPG-key troubleshooting

One of the real problems we hit was a missing-key failure for the Xilinx application PPA:

Err: http://ppa.launchpadcontent.net/xilinx-apps/ppa/ubuntu jammy InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 8FF9183FC8396160

First confirm that the board can actually reach the repository:

ping -c 4 ppa.launchpadcontent.net
curl -I http://ppa.launchpadcontent.net/xilinx-apps/ppa/ubuntu/dists/jammy/InRelease
sudo apt update

If the missing-key error remains, the quick compatibility fix on Ubuntu 22.04 is:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8FF9183FC8396160
sudo apt update

A more modern keyring-style variant is:

sudo apt install -y gnupg ca-certificates
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 8FF9183FC8396160
gpg --export 8FF9183FC8396160 | sudo tee /etc/apt/trusted.gpg.d/xilinx-apps.gpg >/dev/null
sudo apt update

If xlnx-config.sysinit created the repo files, rerunning it after the network is stable can also help refresh the setup:

xlnx-config.sysinit
sudo apt update

Keep this section. The PPA key problem was one of the actual bring-up issues, not theoretical cleanup.

13. Firmware update notes

Firmware matters on KV260, but it should be handled deliberately.

AMD's Ubuntu 22.04 Kria page says KV260 and KR260 can require updated firmware for full functionality, and that if an Ubuntu 22.04 image does not boot due to firmware mismatch you may need a working image or the standalone firmware update and recovery utility. Xilinx Wiki

Check current boot firmware status with:

sudo xmutil bootfw_status

Update firmware only when the selected image or workflow actually requires it:

sudo xmutil bootfw_update -i BOOT.BIN

AMD's KV260 guide documents Linux-based A/B QSPI firmware update tools and a separate recovery path. AMD Documentation

Do not run firmware update commands casually. If the board already boots and the problem is only application selection, stay at the xmutil and firmware-package layer instead of rewriting QSPI.

14. SSH and baseline tools

Install SSH if needed:

sudo apt install -y openssh-server
sudo systemctl enable --now ssh
ip addr
ssh ubuntu@KV260_IP_ADDRESS

Set up SSH keys:

ssh-keygen -t ed25519 -C "kv260"
ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu@KV260_IP_ADDRESS

If ssh-copy-id is unavailable:

cat ~/.ssh/id_ed25519.pub
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

After key login works, harden SSH:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Validate and restart:

sudo sshd -t
sudo systemctl restart ssh

Install baseline tools:

sudo apt install -y \
  build-essential cmake git curl wget vim htop tmux rsync unzip xz-utils \
  python3-pip python3-venv python3-dev pkg-config v4l-utils i2c-tools ffmpeg \
  gdb strace ltrace usbutils pciutils

15. Use xmutil

Core commands:

sudo xmutil listapps
sudo xmutil unloadapp
sudo xmutil loadapp kv260-smartcam
sudo xmutil desktop_disable
sudo xmutil desktop_enable

Observed behavior from our setup:

Use sudo for xmutil in this environment.
Before SmartCam or BIST firmware is loaded, listapps may show the starter platform:
  k26-starter-kits / XRT_FLAT
That is not the same thing as having the SmartCam app loaded.

AMD's Smart Camera documentation explains that xmutil loads application firmware dynamically after Linux has booted, and warns that desktop_disable makes the monitor go blank. xilinx.github.io

16. Run BIST first

BIST is a useful sanity check before SmartCam or custom accelerator work.

sudo apt update
sudo apt install -y xlnx-firmware-kv260-bist
sudo xmutil listapps
sudo xmutil unloadapp
sudo xmutil loadapp kv260-bist

If BIST does not appear immediately:

sudo reboot
sudo xmutil listapps

In our setup, xlnx-firmware-kv260-bist installed cleanly once the Xilinx application PPA was reachable and trusted.

17. Run Smart Camera on Ubuntu 22.04

Use Ubuntu 22.04 for Smart Camera because the prebuilt tutorial and validated app flow target the AMD 2022.1 stack. xilinx.github.io

Install the firmware package:

sudo apt update
sudo apt search xlnx-firmware-kv260
sudo apt install -y xlnx-firmware-kv260-smartcam

Load the SmartCam firmware:

sudo xmutil listapps
sudo xmutil unloadapp
sudo xmutil loadapp kv260-smartcam
sudo xmutil listapps

Pull the Docker image if needed:

docker pull xilinx/smartcam:2022.1

Run the container:

docker run \
  --env="DISPLAY" \
  -h "xlnx-docker" \
  --env="XDG_SESSION_TYPE" \
  --net=host \
  --privileged \
  --volume="$HOME/.Xauthority:/root/.Xauthority:rw" \
  -v /tmp:/tmp \
  -v /dev:/dev \
  -v /sys:/sys \
  -v /etc/vart.conf:/etc/vart.conf \
  -v /lib/firmware/xilinx:/lib/firmware/xilinx \
  -v /run:/run \
  -it xilinx/smartcam:2022.1 bash

Inside the container, this was the working path we validated:

cd /opt/xilinx/kv260-smartcam/bin

Working MIPI camera and DisplayPort command:

./smartcam --mipi --target dp --width 1920 --height 1080 --aitask facedetect --report --screenfps

But in our testing, refinedet behaved better than facedetect:

./smartcam --mipi --target dp --width 1920 --height 1080 --aitask refinedet --report --screenfps

We also saw GLib and GObject warnings from plugin scanning in helper scripts. If the camera opens, output appears, and FPS is being reported, debug the actual pipeline before assuming every GLib warning is the root problem.

18. Smart Camera hardware notes

Preferred hardware path:

Preferred display: 1080p or 4K monitor through DP or HDMI
Preferred camera: AR1335 IAS module in J7
Optional input: USB webcam
Optional client output: RTSP stream to another PC

Observed notes from our run:

MIPI camera input worked.
DisplayPort output worked.
The image was rotated clockwise by 90 degrees.
facedetect was unreliable.
refinedet was more useful for confirming that the pipeline was functioning.

For the 90-degree rotation issue, the prebuilt SmartCam path does not expose a convenient rotation flag. The practical choices are:

Fastest workaround:
- Physically rotate the camera or display for the demo.

Software workaround:
- Use a custom GStreamer pipeline with videoflip.
- Modify or rebuild the host application or output pipeline.

For weak facedetect behavior, first confirm that the pipeline is healthy with refinedet, then improve lighting, face angle, framing, and focus.

19. Camera checks

ls /dev/video*
v4l2-ctl --list-devices
media-ctl -p

Common camera issues:

Wrong camera connector
Wrong IAS module
Bad ribbon cable orientation
Desktop using display resources needed by app
Firmware app not loaded
Wrong Ubuntu image for the application
Wrong Docker image tag
Power or thermal issue

For RTSP playback on another machine:

ffplay rtsp://BOARD_IP:PORT/test

20. Docker, storage, and external media

Check Docker and images:

docker --version
sudo docker run --rm hello-world
sudo usermod -aG docker $USER
groups
docker images

If storage is tight:

docker image prune -a
sudo apt autoremove --purge -y
sudo apt autoclean
df -h
lsblk -f
sudo du -hxd1 / | sort -h

Common storage hogs:

Docker images
Build directories
Vitis/Vivado output
Video files
Datasets
Model files
Downloaded app containers

For larger datasets or artifacts, use external USB storage:

lsblk
sudo parted /dev/sda
sudo mkfs.ext4 -L kv260-data /dev/sda1
sudo mkdir -p /data
sudo blkid /dev/sda1
sudo nano /etc/fstab
sudo mount -a
df -h

Do not edit /etc/fstab casually.

21. Stable networking and SSH from anywhere

For normal day-to-day work, first make SSH stable on the local network.

Good options:

Best home or lab option:
- DHCP reservation on the router for the KV260 Ethernet MAC address.

Best direct-laptop option:
- Static IP on the laptop-side Ethernet network and static IP on the KV260.

Good Ubuntu-side option:
- NetworkManager static IPv4 config with nmcli.

Useful commands:

ip -4 addr
hostname -I
nmcli device status
nmcli con show

Example direct-link setup:

sudo nmcli con mod "Wired connection 1" ipv4.addresses 192.168.50.2/24 ipv4.method manual
sudo nmcli con down "Wired connection 1"
sudo nmcli con up "Wired connection 1"

For remote access beyond the local network, prefer a VPN or jump-host model over direct public SSH port forwarding.

22. Git, Git LFS, and Python environment

Set up Git:

sudo apt install -y git git-lfs
git config --global user.name "Anthony Kung"
git config --global user.email "hi@anth.dev"
git config --global core.editor "vim"
git config --global init.defaultBranch main
git lfs install

Track large files:

git lfs track "*.xclbin"
git lfs track "*.bit"
git lfs track "*.dtbo"
git lfs track "*.hwh"
git lfs track "*.onnx"
git lfs track "*.xmodel"
git lfs track "*.mp4"
git lfs track "*.zip"
git add .gitattributes
git commit -m "Configure Git LFS"

Create a Python environment:

mkdir -p ~/projects
cd ~/projects
python3 -m venv kv260-env
source kv260-env/bin/activate
python -m pip install --upgrade pip setuptools wheel
pip install numpy scipy matplotlib opencv-python

For accelerated inference, do not randomly mix host-installed Python packages with the application container and runtime stack unless you know exactly which runtime is active.

23. Kria host, accelerator, and buffer model

For mental clarity, split the board into two worlds:

Processing system (PS):
- Arm CPU cores
- Ubuntu Linux
- Docker runtime
- Host application
- Camera, display, and network control
- XRT and VART runtime calls
- Preprocessing and postprocessing unless accelerated separately

Programmable logic (PL):
- FPGA fabric
- Loaded bitstream or application firmware
- DPU or custom accelerator kernels
- Video pipeline blocks
- DMA-accessible hardware engines

xmutil loadapp loads the application firmware into programmable logic. After Linux sees the overlay, the host application talks to it through XRT, VART, Vitis AI, or a higher-level app wrapper.

Important buffer rule:

A buffer is not automatically an entire video.
A buffer is usually one frame, one tensor, or a small batch or queue.
A video stream is handled by repeatedly filling and processing buffers.

When benchmarking, separate capture, preprocessing, accelerator execution, postprocessing, display or streaming output, and end-to-end latency.

24. Vitis AI and custom model notes

AMD's older KV260 DPU guide describes a DPU-based accelerated path on the starter kit. AMD Documentation

Practical rules:

Use AMD-provided containers and firmware packages when reproducing demos.
Match application, firmware, Docker image, and Ubuntu version.
Use xmutil to load the correct platform before running the container.
Record the platform and xmodel used for every benchmark.

Do not expect a raw PyTorch or ONNX export to run inside SmartCam by being copied onto the board. The loaded accelerator overlay, compiled model artifact, and runtime stack must agree.

Safer custom-model order:

1. Keep the same camera and display path.
2. Keep the same firmware overlay.
3. Replace the model only after confirming target compatibility.
4. Replace labels and config.
5. Replace preprocessing.
6. Replace postprocessing.
7. Only then modify the host pipeline or Docker image.

25. Fan, thermal, and benchmark notes

Cooling should be treated as part of the test setup.

Check fan-related services:

systemctl status fancontrol.service
systemctl status xlnx-configd.service
ls /sys/class/hwmon/
find /sys/class/hwmon -maxdepth 2 -type f -name "pwm*"

Example manual PWM write:

echo 255 | sudo tee /sys/class/hwmon/hwmon1/pwm1
cat /sys/class/hwmon/hwmon1/pwm1

If the value resets, another service is controlling the fan.

Before recording benchmark numbers:

uname -a
lsb_release -a
sudo xmutil listapps
sudo xmutil bootfw_status
df -h
free -h
ip addr
docker images

Always record:

Board name
OS image and version
Kernel version
Boot firmware version
Loaded xmutil app
Application firmware package version
Docker image tag
Runtime stack
Fan policy
Power source
Model file
Input resolution
Input source
Output target
Batch size
Precision
Warm-up time
Average FPS
Latency percentiles
CPU usage
Memory usage
Board power
FPS per watt where meaningful

For the exact SmartCam pipeline we used, keep these commands:

cd /opt/xilinx/kv260-smartcam/bin
./smartcam --mipi --target dp --width 1920 --height 1080 --aitask facedetect --report --screenfps
./smartcam --mipi --target dp --width 1920 --height 1080 --aitask refinedet --report --screenfps

Do not compare Kria and Jetson benchmark numbers unless the app, model, firmware, input path, output path, and thermal state are documented.

26. Backup, systemd, and remote workflow

Back up at least:

/home
/etc
/boot
Custom scripts
Project repositories
xmodel files
Application configs
Custom systemd services
Custom firmware packages
Custom device tree overlays
Benchmark logs

Useful commands:

rsync -aAXH --numeric-ids --info=progress2 /home/ubuntu/ user@backup-server:/backups/kv260/home-ubuntu/
sudo tar -czf kv260-etc-backup.tar.gz /etc
uname -a > kv260-version.txt
lsb_release -a >> kv260-version.txt
sudo xmutil listapps >> kv260-version.txt 2>&1
dpkg -l | grep -E "xlnx|xilinx|vitis|vart|xrt" >> kv260-version.txt

Example service:

[Unit]
Description=KV260 Application
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=ubuntu
WorkingDirectory=/home/ubuntu/projects/kv260-app
ExecStart=/home/ubuntu/projects/kv260-app/kv260-env/bin/python main.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Recommended development workflow:

Use serial console for boot and recovery.
Use SSH for normal terminal access.
Use VS Code Remote SSH for editing.
Use tmux for long-running commands.
Use rsync or Git for transfer.
Use Docker for packaged demos.
Use wired Ethernet for demos and benchmarks.

27. Common problems

Xilinx PPA reports NO_PUBKEY 8FF9183FC8396160

This matched a real issue we hit. Re-run the key import and update steps from the repository section.

SmartCam runs but face detection is weak

This also matched our run. Test refinedet first:

cd /opt/xilinx/kv260-smartcam/bin
./smartcam --mipi --target dp --width 1920 --height 1080 --aitask refinedet --report --screenfps

If refinedet works but facedetect is weak, the likely issue is model-task suitability, lighting, framing, or rotation rather than total board failure.

Camera is rotated 90 degrees

That also matched our actual run. For quick demos, use a physical workaround. For a clean fix, modify the pipeline or host application and rebuild.

GLib or GObject warnings appear

Do not assume those warnings are the primary bug if the camera opens, output displays, and FPS is being reported.

Board has power LEDs but no terminal output

Check:

Correct serial port selected
FTDI driver installed
Correct baud rate: 115200
Good USB cable
Board powered through 12V adapter
microSD card inserted
Image written correctly

xmutil listapps shows nothing useful

Try:

sudo apt update
sudo apt search xlnx-firmware-kv260
sudo xmutil listapps
sudo apt install xlnx-firmware-kv260-smartcam
sudo xmutil listapps

Monitor goes blank after desktop_disable

That is expected. Continue through UART or SSH, then re-enable the desktop if needed:

sudo xmutil desktop_enable

28. Final verification checklist

System:

uname -a
lsb_release -a
hostnamectl
timedatectl

Boot and app state:

sudo xmutil listapps
sudo xmutil bootfw_status

Network:

ip addr
ping -c 4 google.com

Storage:

df -h
lsblk -f

Packages:

dpkg -l | grep -E "xlnx|xilinx|xrt|vart|vitis"
snap list | grep xlnx

Docker:

docker --version
docker images

Camera:

ls /dev/video*
v4l2-ctl --list-devices
media-ctl -p

SSH:

systemctl status ssh

Git:

git --version
git config --global --list

29. Operational notes

Use Ubuntu 24.04 for general KV260 evaluation and server-style development.

Use Ubuntu 22.04 when reproducing AMD's validated example applications such as Smart Camera, AI Box ReID, Defect Detect, NLP SmartVision, AI Box Distributed ReID, and DFX. xilinx.github.io

Do not use Ubuntu Core 24 as the default for this guide because Canonical marks it as developer preview for Kria. Ubuntu

Use the microSD image method for normal bring-up.

Remember that QSPI boot firmware and SD card Linux are separate. Updating the SD card image is not the same thing as updating QSPI boot firmware.

Do not update QSPI firmware unless the image, application flow, or recovery path requires it.

Use xlnx-config for Ubuntu 22.04 demo-environment initialization.

Use xmutil to list, load, and unload accelerated applications.

Use UART or serial access for recovery and for workflows that disable the desktop.

Use wired Ethernet for RTSP, demos, package installation, and stable remote development.

Use Docker only when there is enough SD card or external storage space.

Use Git LFS for large FPGA, Vitis, video, and model artifacts.

Record Ubuntu version, boot firmware status, loaded app, Docker image tag, model file, and input-output pipeline for every benchmark.

Project-specific final notes:

The guide date remains April 15, 2026.
The working path we actually used is Ubuntu 22.04 + xlnx-config + Xilinx app PPAs + SmartCam.
Ubuntu 24.04 remains useful, but it is not the validated SmartCam path we proved.
The exact working SmartCam command should stay in the guide.
The PPA/GPG troubleshooting should stay in the guide.
The refinedet-vs-facedetect observation should stay in the guide.
The camera-rotation caveat should stay in the guide.
Stable SSH/static IP should be completed before long benchmark runs.