The purpose of this page is to provide developers with information and links to collateral available for the Kria Production SOMs and Starter Kits, including documentation, pre-built images, firmware updates, and GitHub repositories. It is meant to augment other official documentation found at the Kria SOM product page at amd.com.

Table of Contents

Kria Platforms Overview

Xilinx Kria is a portfolio of System-On-Modules (SOMs) designed for edge applications in a variety of use cases and production settings. The K26 and K24 SOMs are meant to be integrated directly into a customers production design and the SOM Starter Kit (e.g. KV260, KR260, KD240) are an evaluation and early development platform. The Kria lineup simplifies and accelerates the system development, helping you get your product to market faster.

Production SOMs

K26

The K26 system-on-module (SOM) is a production ready hardware platform. The K26 SOM is shipped without any preloaded FW or SW configurations in the non-volatile memory devices (QSPI and eMMC). The K26 SOMs do not include ECC support.

Open

K24

The K24 system-on-module (SOM) is a production ready hardware platform. The K24 SOM is shipped without any preloaded FW or SW configurations in the non-volatile memory devices (QSPI and eMMC). The I-grade K24 SOM includes ECC support while the C-grade K24 SOM does not.

Open

Starter Kits

Kria Starter Kits are intended to be used for initial evaluation and early development platform for the K26 and K24 SOM. They consist of either a K26 or K24 SOM coupled with an application focused carrier card. The Kria Starter Kits are shipped with a pre-loaded boot FW stored in the QSPI non-volatile memory device and a preset boot mode configuration of QSPI32. Details on QSPI memory configuration and content are outlined below. A pre-built Kria Starter Kit Linux image is provided for each SOM variant set of Starter Kits. Pre-built applications are then made available over-the-air (OTA) via Linux package feeds. Details on the Kria Starter Kit Linux images and example applications are outlined below.

KV260 Starter Kit

The KV260 is an evaluation kit based on the K26 SOM focused on vision applications.

KR260 Starter Kit

The KR260 is an evaluation kit based on the K26 SOM focused on robotics and machine vision applications.

KD240 Starter Kit

The KD240 is an evaluation kit based on the K24 SOM focused on electric drives and motor applications.

Kria Product Summary

As outlined on this page there are variants of production and corresponding starter kit SOMs. The starter kits are built with SOMs that are component/part population only variants of the production SOM. The following table summarizes the key functional difference in the Kria product variants.

Getting Started

First time Kria Starter Kit users should refer to the on-line “Getting Started” guide for their kit:

• KV260 Vision Starter Kit Getting Started

• KR260 Robotics Starter Kit Getting Started

• KD240 Drives Starter Kit Getting Started

Developer Resources

The following section provides links to the product documentation, pre-built firmware and software binaries, and application examples.

The Kria adventure map is a map of links to help users discover useful documentation according to their evaluation stages.

Additional technical assets and resources such as 3D CAD model, bill of materials, carrier schematic, carrier PCB layout and schematic source files can be accessed in the Carrier Card Design Resources section of the following Kria Starter Kit product pages:

• Kria KD240 Drives Starter Kit

• Kria KR260 Robotics Starter Kit

• Kria KV260 Vision AI Starter Kit

K26 Documentation

• K26 Datasheet (DS987)

• KV260 Datasheet (DS986)

• KR260 Datasheet (DS988)

• KV260 User Guide (UG1089)

• KR260 User Guide (UG1092)

K24 Documentation

• K24 Datasheet (DS985)

• KD240 Datasheet (DS984)

• KD240 User Guide (UG1093)

Kria Shared Documentation

• Xilinx SOM Carrier Card Design Guide (UG1091)

• Kria App Developer Guide

• Kria Starter Kit Boot FW Guide

• Kria Robotics Stack (KRS)

Starter Kit Pre-Built Software

The Kria Starter Kits use a two stage boot process. The primary boot firmware is pre-installed at the factory on the QSPI device. The secondary boot device is an SD card containing the Linux kernel and Linux root filesystem (rootfs). The Starter Kit pre-built FW and SW are aligned with their specific Starter Kits. The K26 and K24 Starter Kit SD card images are available in the tables below. When using pre-built applications from the Xilinx App Store you need to ensure to align your Starter Kit Linux version with the target application assumed Linux version.

The K26 based Starter Kits are supported with Ubuntu Desktop 22.04 and the K24 Starter Kits are supported with Ubuntu Server 22.04. The configurations between the two Ubuntu OS are primarily the same with the primary functional difference being the inclusion of the desktop GUI.

K26 Starter Kit Linux

The K26 Kria Starter Kits supported with Ubuntu Desktop 22.04 for the initial out-of-box support and example applications. An embedded Linux built within Yocto is also provided as a reference implementation for customers intending to target a custom embedded Linux during evaluation and production. Each Starter Kit also has a corresponding PetaLinux BSP. The Ubuntu Desktop 22.04 is the primary OS targeted by the KV260 and KR260 pre-built applications and out of box workflows.

Ubuntu Desktop LTS

The following table outlines the Ubuntu images available for the Kria Starter Kit. For additional details on the Ubuntu support for Kria see the Xilinx Ubuntu Wiki. Kria Ubuntu default login:

• Username: ubuntu

• Password: ubuntu (Will be prompted to change on first login)

K26 Embedded Linux (Yocto)

Starting with 2023.1 the Kria Starter Kits embedded Linux reference image has been built natively in Yocto to support users not using the Xilinx specific PetaLinux tool. The Kria Yocto reference image is built to support multiple platforms while the PetaLinux BSPs only support a single static HW configuration. Thus you will find a Yocto reference image that supports both K26 Starter Kits (KV260, KR260), while PetaLinux has a 1-to-1 mapping of BSPs to individual platforms. For additional details on Kria platform Yocto support see the Kria App Dev Guide. For details on Yocto vs PetaLinux support for KRia, refer to Kria SOMs & Starter Kits | Yocto Vs PetaLinux Support and Released Artifacts. Yocto image default login:

• Username: petalinux

• Password: Will be prompted to change on first login

K26 PetaLinux

The following table outlines the PetaLinux based pre-built Linux images. Default login:

• Username: petalinux

• Password: Will be prompted to change on first login

K26 Boot Firmware Updates

K24 Starter Kit Linux

The K24 Kria Starter Kits supported with Ubuntu Server 22.04 for the initial out-of-box support and example applications. An embedded Linux built within Yocto is also provided as a reference implementation for customers intending to target a custom embedded Linux during evaluation and production. Each Starter Kit also has a corresponding PetaLinux BSP. The Ubuntu Server 22.04 is the primary OS targeted by the KD240 pre-built applications and out of box workflows.

Ubuntu Server LTS

The following table outlines the Ubuntu images available for the K24 Kria Starter Kit. For additional details on the Ubuntu support for Kria see the Xilinx Ubuntu Wiki. Kria Ubuntu default login:

• Username: ubuntu

• Password: ubuntu (Will be prompted to change on first login)

Known issue:

• on certified Ubuntu 22.04 kd05, RS485 driver is not present as it is in the process of being upstreamed. It is still available on Ubuntu 22.04 kd03 version

K24 Embedded Linux (Yocto)

The K24 Kria Starter Kits embedded Linux reference image has been built natively in Yocto to support users not using the Xilinx specific PetaLinux tool. The Kria Yocto reference image is built to support multiple platforms while the PetaLinux BSPs only support a single static HW configuration. Thus you will find a Yocto reference image that supports both K24 Starter Kits (KD240), while PetaLinux has a 1-to-1 mapping of BSPs to individual platforms. For additional details on Kria platform Yocto support see the Kria App Dev Guide. For additional details on Kria platform Yocto support see the Kria App Dev Guide. For details on Yocto vs PetaLinux support for KRia, refer to . Yocto image default login:

• Username: petalinux

• Password: Will be prompted to change on first login

Known issue:

• RS485 Driver is not integrated in PetaLinux 2023.2, refer to AR000035701 for more information.

K24 Boot Firmware Updates (Yocto)

On-Target Utilities

The Kria runtime software provides a number of platform management helper utilities available under a common wrapper called “xmutil”. The following table summarizes these utilities which can be called using “xmutil <utility name>” in both Starter Kit Linux OS variants available. Use the -h or help functions with each utility to get detailed use instructions. Using sudo is required with many of the xmutil functions. The utilities and procedures are the same for all Kria Starter Kits.

Boot FW Update Process

Boot FW QSPI Memory Map

The boot FW of the Kria Starter Kits is pre-loaded at time or production in the SOM QSPI memory. This device is intentionally isolated from the SD card to ensure that the board is always in a bootable state and SW developers can primarily focus on OS level updates and late bound loading of bitstreams. Sectors of the QSPI device are locked during production to prevent accidental overwrite in customer systems; with the only sectors that can be over-written are the A and B boot partitions discussed above and supported by the xmutil and Boot Image Recovery tools. The QSPI memory map and read/write access is defined in the following table.

Bitstream Management

The Kria Starter Kits use a dynamic bitstream management practice to allow different application bitstreams to be swapped without rebooting the entire platform. The default behavior of Kria Starter Kits is that the platform is booted to Linux with no bitstream loaded. A daemon called dfx-mgr provides the infrastructure for tracking bitstreams that are on the file system and loading/unloading the different bitstreams and their device tree overlays. For details on dfx-mgr operation see:

A default bitstream is loaded after boot as part of the dfx-mgr startup, which bitstream is loaded is determined by the dfx-mgr daemon configuration file located in “/etc/dfx-mgrd/daemon.conf”. Kria Starter Kit Linux images include a default bitstream loaded is called “k2*-starter-kits” has no functional PL logic but provides an EMIO mapping to the carrier card fan control pin via an EMIO and enables the PL SysMon functionality. Removing this bitstream will effectively disable active fan control as the physical pin is no longer accessible to Linux.

Fan Control

Starting with the 2022.1 images Kria Starter Kit pre-built software includes active fan control using the Linux fancontrol library which uses ZU+ PS TTC0 subsystem. The K26 Starter Kit fan pin is connected to PL pin HDA20 (physical pin A12) and thus in order to access it users need to ensure to provide an EMIO pin mapping between TTC0-Clk2 and HDA20. This is accounted for in the Xilinx generated platforms and reference bitstreams. If user wants to use the same fan control mechanism then they need to account for this EMIO mapping when generating their custom bitstream designs.

The KD240 Starter Kit ships with a passive heatsink but does have HW hooks for active fan control via J13 jumper on the KD carrier card if users want to add a 12V fan to their system. In K24 the fan control pin is connected to HDA08_CC PL pin.

PetaLinux & Ubuntu LTS

Kria is supported with both a pre-built Ubuntu LTS Linux image as well as being enabled within the PetaLinux development tool and Xilinx Yocto layers. The following table provides an summary of the intended scope that Ubuntu and PetaLinux have in the context of Kria SOM and Starter Kits, supporting the development life-cycle from initial out-of-box (OOB) evaluation to customer end product production.

AMD-Xilinx Tools Support

Yocto Build instructions

Starting from 2023.1, there is Yocto support for Kria SOM Starterkits. Refer to Yocto Kria Support documentation for more information. There are support for generating .wic image, boot.bin or qspi images.

PetaLinux Board Support Packages

PetaLinux Board Support Packages (BSP) include pre-built images and a pre-defined configuration to rebuild the images from scratch.

K26 Platforms

The Kria K26 products are supported with three BSPs which are analogous to the “SOM” and “Starter Kit” hardware configurations outlined above. Be sure to use the BSP aligned with your selected tools version and target platform.

K24 Platforms

The Kria K24 product is supported with two BSPs which are analogous to the “SOM” and “Starter Kit” hardware configurations outlined above. Be sure to use the BSP aligned with your selected tools version and target platform.

PetaLinux Tools Release Notes

PetaLinux 2023.1 Release

The Kria K26 platforms are supported in the original PetaLinux 2023.1 release, which can be found in PetaLinux 2023.1 tools download page.

The Kria K24 platforms require the PetaLinux “Update 1” tools package to be installed via the PetaLinux upgrade process to use the K24C and KD240 PetaLinux BSPs. See the PetaLinux upgrade instructions at this link.

PetaLinux 2022.1 Release

The Kria SOM is supported in the PetaLinux 2022.1 release through an eSDK update captured under the 2022.1 PetaLinux Update 1, you need to ensure you upgrade your PetaLinux 2022.1 installation prior to using the Kria Starter Kit 2022.1 BSPs.

PetaLinux Build instructions

Building with PetaLinux tool is dependent on first having a proper PetaLinux install aligned with the BSP version being used. See PetaLinux user guide (UG1144) for install requirements and instructions. Most Kria BSPs are release asynchronous to the main tools release and require an eSDK update prior to building with the corresponding Kria BSP. See the Kria PetaLinux BSP table above for guidance.

The following provide short-hand instructions for building a Kria BSP, which given the primary/secondary boot design requires special handling in steps #4 and #5 relative to non-primary/secondary boot platforms.

1. petalinux-create -t project -s <kria_starterkit>.bsp

2. cd <kria_starter_kit_petalinux_folder>

3. petalinux-build

4. petalinux-package --boot --u-boot --force

5. Final image packaging steps by platform

   1. 2023.2 for KV260, KR260, KD240:

      1. KV260: petalinux-package --wic --images-dir images/linux/ --bootfiles "ramdisk.cpio.gz.u-boot,boot.scr,Image,system.dtb,system-zynqmp-sck-kv-g-revB.dtb"

      2. KR260: petalinux-package --wic --images-dir images/linux/ --bootfiles "ramdisk.cpio.gz.u-boot,boot.scr,Image,system.dtb,system-zynqmp-sck-kr-g-revB.dtb"

      3. KD240: petalinux-package --wic --images-dir images/linux/ --bootfiles "ramdisk.cpio.gz.u-boot,boot.scr,Image,system.dtb,system-zynqmp-sck-kd-g-revA.dtb"

   2. 2022.1, 2022.2, 2023.1:

      1. KV260: petalinux-package --wic --images-dir images/linux/ --bootfiles "ramdisk.cpio.gz.u-boot,boot.scr,Image,system.dtb,system-zynqmp-sck-kv-g-revB.dtb" --disk-name "mmcblk1"

      2. KR260: petalinux-package --wic --images-dir images/linux/ --bootfiles "ramdisk.cpio.gz.u-boot,boot.scr,Image,system.dtb,system-zynqmp-sck-kr-g-revB.dtb" --disk-name "sda"

      3. KD240 ( 2023.1 only) : petalinux-package --wic --images-dir images/linux/ --bootfiles "ramdisk.cpio.gz.u-boot,boot.scr,Image,system.dtb,system-zynqmp-sck-kd-g-revA.dtb" --disk-name "sda"

   3. 2020.2 & 2021.1 BSPs (KV260 only): petalinux-package --wic --bootfiles "ramdisk.cpio.gz.u-boot boot.scr Image system.dtb"

Regenerating boot firmware from BSP

After building PetaLinux, enter below command to generate a new BOOT.BIN. Note if only developing and adjusting Linux functionality a user does NOT need to update the BOOT.BIN of the target.

You will find new boot firmware at /image/linux/BOOT.BIN. The new BOOT.BIN can be loaded to the Starter Kit using the xmutil bootfw_update utility described above

Yocto Vs PetaLinux Support and Released Artifacts

The table below summarizes Yocto and PetaLinux support for the various platforms within Kria product family.

Vivado Board Support Packages

The Kria SOMs and Starter Kits are supported by Vivado with board files that automate the configuration of the SOM based peripherals. These board files are available on Xilinx’s GitHub Board Store and are supported in Vivado via installation from the XHUB store. Please make sure to use the correct released version corresponding to your chosen BSP/tool version. Note that there are “Starter Kit” SOM board files for each Starter Kit due to their differences detailed in this earlier section.

Instruction to get from XHUB store

Board files can be installed from XHUB Stores by clicking “tools”-> “Vivado board stores” and selecting the board file to install. When using Starter Kit, make sure to install both the Starter Kit SOM (e.g. Kria KR260 Robotic Starter Kit in snapshot below) and the Carrier Card (e.g. Robotics Starter Kit carrier card in snapshot below).

Instructions to download from repo

Alternatively, user can manually download the board files from either board store repo or kria-vitis-platforms repo

and then in Vivado tcl console:

for an example:

SOM XDC Files

The SOM XDC files are linked as part of a set of files supporting the respective carrier card design guide. Direct links provided here:

• K26 SOM XDC - XTP685

• K24 SOM XDC - XTP778

Kria Accelerated Applications

The Xilinx Accelerate Applications are example designs pre-built and deployed to a Kria Starter Kit. These accelerated application examples or “AAs” are available are updated asynchronous to the main Xilinx tools releases, but do have dependencies on a corresponding OS. The following table provides a summary of the apps and which of the Kria Linux OS release they are available in. For latest list of all applications, their GitHub repos, and step-by-step application steps refer to the platforms landing pages linked in the table below.

Kria Platform Utilities

The Kria Starter Kits use a number of on-target utilities that may be useful in your design.

• linux-image-update

  • Description - Linux utility for updating A/B boot firmware partitions of primary boot device.

  • Repository -

• axi-qos

  • Description - Linux utility for on-target adjustment AXI interface quality-of-service.

  • Repository -

• ddr-qos

  • Description - Linux utility for on-target adjustment PS subsystem DDR4 interface quality-of-service.

  • Repository -

• platformstats

  • Description - Linux utility for collecting platform statistics including die temperature, CPU speed, power utilization, etc.

  • Repository -

• xmutil

  • Description - Linux front-end utility focused on embedded platforms and SOM Starter Kits.

  • Repository -

• image-recovery (Boot Image Recovery Tool)

  • Description - Stand-alone application using web-server for boot firmware recovery.

  • Repository -

• image-selector

  • Description - Stand-alone application used to implement A/B firmware selection at MPSoC boot.

  • Repository -

• kria-dashboard

  • Decryption - GUI based dashboard displaying information from platformstats, and basic application downloading, loading and unloading cockpit

  • Repository -

• resize-part

  • Description: expand partition tool in default BSP to expose full SD card space for Linux partition

  • Repository -

PL & HW Repositories

• Pre-built application bitstreams

  • Description: Pre-built bitstreams (*.bit) and corresponding device tree overlays (*.dtsi)

  • Repository -

• Kria Vitis platforms

  • Description: Vitis platforms for Kria Starter Kits (SOM only meaning no CC peripherals implemented), KR260 Starter Kit, and KV260 Starter Kit

  • Repository -

Custom & Production SOM Design Guidance

Hardware

The Kria SOM Carrier Card Design Guide in UG1091 provides guidance on design of custom carrier card design for both K24 and K26 SOM based designs.

A Kria carrier card schematic checklist has also been created to help custom carrier card hardware development in XTP748.

K26 Devices

The following table captures the Kria K26 SOM memory device part numbers for reference in custom HW and SW designs.

K24 Devices

The following table captures the Kria K24 SOM memory device part numbers for reference in custom HW and SW designs.

K26 Qualification Data

The below table shows FIT and MTBF at 40°C under 50% Electrical Load

 For obtaining more details of the reliability stress tests (test conditions & results) and the Reliability Prediction Model, please request access to the Kria SOM Qualification Report Lounge containing RPT264 - Kria K26 SOM Qualification Report

Firmware

This section captures guidance on FW configurations that a Kria SOM developer should be aware of when creating custom firmware and carrier card designs.

MPSoC PMU FW

The MPSoC PMU is used to implement the platform interactions with the SOM power management ICs. Given this coupling between the SOM HW design and PMU FW there are a few PMU controlled MIO signals that require special design considerations. For details on MPSoC FW implementation see the PMU Firmware Wiki. . The PMU GPIO connection to MIOs can be found and enabled in Kria SOM’s Vivado designs in the Processor Subsystem configuration – “I/O Configuration” tab, under “Low Speed” -> “I/O Peripherals” -> “PMU”.

• PMU GPI (MIO31): The MIO31 pin is mapped to PMU GPI 5 and it is an CC optional PMU input pin that can be used for customer functionality such as an external platform shutdown request (e.g. carrier card push-button). The pin is mapped in the same manner in both K26 and K24 SOMs. The corresponding PMU optional runtime feature is implemented using the PMU FW build-time PMU_MIO_INPUT_PIN in PMUFW.

• PMU GPO (MIO35): The MIO35 pin is an CC optional PMU output pin that can be used for customer functionality such as an external platform such as an external POR_B reset or an external watchdog interface. The pin is mapped in the same manner in both K26 and K24 SOMs to PMU GPO3. The Kria carrier cards do have different mappings of this pin to CC based functionality.

  • KD240 - Maps the pin to allow the option for PMU to command a POR_B reset of the SOM during reboot processes. This will also cause a full reset of the TPM device of the SOM. The corresponding flag in PMU FW is EXT_RESET_GPO_PIN.

  • KR260 & KV260 - Maps the pin to an external watchdog. The corresponding PMU optional runtime feature is implemented using the PMU FW build-time flag ENABLE_RUNTIME_EXTWDT.

• SOM_PWR_KILL (MIO34): The PMU controls the overall SOM power enable signal, which is used during shutdown of the platform to disable the power supplies. The PMU GPO2 signal is used to control to physical pin MIO34, which is connected to the SOM PS_PWR_EN signal. The corresponding macro in PMUFW is BOARD_SHUTDOWN_PIN. The SOM design has a 10kohm pull-up resistor on the signal, but as part of the boot process and the MPSoC dynamic MIO pin selection a developer needs to ensure that they set PMU build time configuration CONNECT_PMU_GPO_2_VAL= 0 . Without this setting there is potential of a glitch on the PS_PWR_EN signal. Details are captured at this Xilinx AR-71952. This pin is used in the same manner in both K26 and K24 SOMs and is not mapped to the SOM/CC connector.

• PL_PWR_EN (MIO33): The PL power domain of the Kria SOMs can be shutdown independently of the PS (FPD + LPD) power domain. In K24 this is handled with the SOM reserved PMU GPO pin MIO33. To use the feature in custom designs the user should enable the PMU GPO1 pin in their Vivado project. In K26 the PMU cannot directly control the PL power domain and the PL power domain can only be controlled via a Linux owned I2C interface. The PL power domain will be automatically powered off with the SOM_PWR_KILL. There is no macro for this pin in PMUFW, however, it is initialized in psu_init with register name IOU_SLCR_MIO_PIN_33_OFFSET.

• Runtime Temperature OT: The PMU has an optional feature of implementing an over-temperature monitoring, using the MPSoC SysMon as the temperature feedback. This is implemented using the PMU FW build-time flag ENABLE_RUNTIME_OVERTEMP.

Linux

This section captures guidance on Linux SW configurations that a Kria SOM developer should be aware of when creating their production Linux images.

Fan Control

Linux fan control library and its use in the ZU+ target requires the following Linux kernel configurations to be enabled:

• CONFIG_SENSORS_PWM_FAN=y

• CONFIG_PWM=y

• CONFIG_PWM_CADENCE=y

The PS subsystem device tree must include the desired TTC node and that node must include the "pwm-cells" property.

Known Issues & Limitations

The following section outlines the known issues and limitations for the Kria platforms.

All Starter Kits

Ubuntu

K24 & KD240 Starter Kit