Kria K26 SOM

The purpose of this page is to provide developers with information and links to collateral available for the Kria K26 SOM, 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 Xilinx.com.

Table of Contents

Introduction

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

K26 SOM

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).

Starter Kits

Kria Starter Kits are intended to be used for initial evaluation and early development of the K26. They consist of the K26 SOM and 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 common pre-built Kria Starter Kit Linux image is provided and is capable of booting on both KV260 and KR260. Pre-built applications are then made available over-the-air (OTA) via Linux package feeds. Details on the Kria Starter Kit Linux and example application install are outlined below.

KV260 Starter Kit

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

KV260 Starter Kit
KV260 Starter Kit Interfaces

KR260 Starter Kit

The KR260 is an evaluation kit based on the K26 SOM focused on robotics and machine vision applications. 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.

KR260 Starter Kit
KR260 Starter Kit Functional Interfaces

 

Both the K26 SOM and the KV260 Starter Kit are sold in encryption enabled (G) and encryption disabled (-ED) variants. This designation refers to the availability of the MPSoC hardened crypto block that enables the SHA and AES accelerator functions.

Getting Started

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

Developer Resources

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

Documentation

Starter Kit Pre-Built Software

The SOM 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 SD card images are available in the table 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.

Kria Starter Kit Linux

The Kria Starter Kits supported with both Ubuntu 22.04 and PetaLinux. The Ubuntu 22.04 is the primary OS targeted by the Xilinx pre-built applications and out of box workflows. PetaLinux images and Yocto integrations are available to support users intending to target a custom embedded Linux during evaluation and production.

Ubuntu 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.

Default login:

  • Username: ubuntu

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

Kira Starter Kit users of Ubuntu 22.04 LTS should update their boot FW to the recommended version in the table below to ensure full platform functionality.

Legacy KV260 kits REQUIRE the 2022.1 boot FW update prior to booting Ubuntu 22.04. Update should be completed with your current Linux image or via the Image Recovery tool.

Starter Kit Ubuntu Image

Description

Kits Supported

Recommended FW

Download Link

Starter Kit Ubuntu Image

Description

Kits Supported

Recommended FW

Download Link

Ubuntu 22.04 LTS

Kria Starter Kit Ubuntu 22.04 LTS image

Currently available only as a beta release.

KV260, KR260

2022.1 Boot FW Update

https://ubuntu.com/download/amd-xilinx

Ubuntu 20.04 LTS

Kria Starter Kit Ubuntu 20.04 LTS image

KV260

2021.1 Boot FW Update 2 or later

https://ubuntu.com/download/amd-xilinx

Kria Ubuntu 22.04 LTS has the following known limitations:

  • Suspend/resume functionality is not supported including Ethernet wake-on-LAN (WOL)

  • via-lab chipset based USB hubs will cause boot failure. Recommendation to use USB devices without a hub.

  • Install of Xilinx application packages causes dfx-mgr to crash. Recommendation to reboot platform or restart dfx-mgr service.

  • xmutil pwrctrl utility functional but does not print status to console

  • Audio playback on DisplayPort occasionally produces a “clicking” noise in concert with actual audio playback

  • KV260: Legacy boot FW (2021.1) will not boot the Ubuntu 22.04 image. Upgrade to 2022.1 Boot FW prior to loading Ubuntu 22.04 image.

  • KR260 USB2.0 devices not functional on U46 interfaces. Upgrade to 2022.1 Boot FW.

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

Starter Kit PetaLinux Image

Description

Kits Supported

Recommended FW

Download Link

Starter Kit PetaLinux Image

Description

Kits Supported

Recommended FW

Download Link

Kria Starter Kit 2022.1

2022.1 PetaLinux Starter Kit Linux pre-built SD card image

KV260, KR260

2022.1 Boot FW Update

Xilinx download

Kria Starter Kit 2021.1

2021.1 PetaLinux Starter Kit Linux pre-built SD card image

KV260

2021.1 Boot FW Update 2 or later

Xilinx download

Kria Starter Kit 2020.2.2

2020.2.2 PetaLinux Starter Kit Linux pre-built SD card image

KV260

2020.2.2 Boot FW Update or later

Xilinx download

Initial SC Card Boot “Update”

After initial boot of a new SD card image it is best practice to execute sudo dnf update (PetaLinux) or sudo apt update (Ubuntu) in order to update core utilities that may have been released following the SD card image release.

In some scenarios it may be required to clean the local dnf cache first. To do so execute sudo dnf clean all

With 2021.1 package feeds when doing dnf update you will see a number packages that are flagged for update but are only revision metadata updates. You do not need to install these dnf tracked changes, but if you do it will only update/align the associated revision information.

Boot Firmware Updates

The SOM Starter Kits have factory pre-programmed boot firmware that is installed and maintained in the SOM QSPI device. Occasionally firmware updates will be made available in the table below which can be updated from Linux using the “xmutil bootfw_update” on-target utility. The starter kits supports an A/B update mechanism to ensure that the platform has a known good fallback in the event of an issue during the upgrade process. The on-target utility will update the new boot firmware (BOOT.BIN file) into the non-active slot and then set the firmware to become active on the next boot cycle.

Kria Boot FW Image

Description

Kits Supported

Download Link

Kria Boot FW Image

Description

Kits Supported

Download Link

2022.1 Boot FW Update

Unified FW for KV260 and KR260 Starter Kits. Addresses KR260 USB2.0 interfaces on U46 connector stack. Addresses KR260 PS Ethernet functionality on J10C physical interface.

KV260, KR260

Xilinx download - BOOT_xilinx-k26-starterkit-v2022.1-05140151_update1.BIN

2021.1 Boot FW Update 2

KV260 boot FW update to address potential platform SW reboot induced failure. Behavior is reboot is not successful as PS power domain is unintentionally disabled.

NOTE: This update is atomic (does not required Update 1 to be installed prior)

KV260

Xilinx download - 2021.1_update2_BOOT.BIN

Do2021.1 Boot FW Update 1

2021.1 aligned boot firmware pre-built content.

NOTE: This update is optional as the 2021.1 SD card image is backwards compatible.

KV260

Xilinx download- 2021.1_update1_BOOT.BIN

2020.2.2 Boot FW Update

PLL configuration update to support Smart Cam audio PLL requirement.

KV260

Xilinx download- BOOT.BIN

Accelerated Applications & Library Packages

The SOM Starter Kits use the Linux dnf package manager to deploy, update, and maintain the accelerated application (AA) and their supporting libraries. The xmutil “getpkgs” function provides an easy to use method to query and identify the packages applicable to the Starter Kit it is actively running on. The “getpkgs” uses normal dnf functionality which is supported and enabled by default in the SOM Starter Linux images. The AA documentation including install, getting started, and how to build is maintained on the Kria GitHub.io documentation pages.

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.

Utility Name

Description

Utility Name

Description

boardid

Reads all board EEPROM contents. Prints information summary to command line interface.

bootfw_status

Reads primary boot device information. Prints A/B status information, image IDs, and checksums to command line interface.

bootfw_update

Tool for updating the primary boot device with a new boot image in the inactive partition.

getpkgs

Queries Xilinx package feeds and provides a summary to the debug interface of relevant packages for the active platform based on board ID information.

listapps

Queries on the target hardware resource manager daemon of pre-built applications that are available on the platform and provides a summary to the debug interface.

loadapp

Loads the integrated HW+SW application inclusive of the bitstream, and starts the corresponding pre-built application software executable.

unloadapp

Removes accelerated application inclusive of unloading its bitstream.

platformstats

Reads and prints a summary of the following performance related information: CPU frequency, RAM usage, temperature, and power information.

ddrqos

Utility for changing configuration of PS DDR quality of service (QoS) settings. Initial implementation focuses on PS DDR memory controller traffic class configuration.

axiqos

Utility for changing configuration of PS/PL AXI interface quality of service (QoS) settings. Initial implementation focuses on AXI port read/write priority configurations.

Boot FW Update Process

For an overview of the Kria Starter Kit A/B boot and primary (QSPI) to secondary (SD card) boot architecture see the Boot Firmware section of the Kria App Developer Guide. The following section provides user facing instructions for using the utilities put in place around this A/B boot architecture to deploy boot FW updates to your platform.

Boot FW via xmutil

The SOM on-target management utility xmutil provides bootfw_update and bootfw_status utility for updating and checking the status of the boot FW from Linux.

Boot FW update with xmutil

The xmutil provides a utility to help in the update of the on-target boot firmware with the following steps:

  1. Download the boot firmware update from the table above. It should be a Xilinx BOOT.BIN file.

  2. Move the BOOT.BIN file to the SOM Starter Kit target using FTP (or similar method). Note when copying file remotely you must copy it to the petalinux user directory.

  3. Execute “sudo xmutil bootfw_update -i <path to boot.bin>”.

  4. After the image write is completed issue a power-on reset. This can be accomplished by pressing the RESET push-button or power cycling the board.

  5. After restart it is required by the user verify that Linux fully boots with the new boot FW to verify functionality. This is completed by executing “sudo xmutil bootfw_update -v to validate successful boot against the new firmware. Note this must be completed on the platform restart immediately following the update, else the platform will fall back to the other boot partition on the next restart.

Boot FW status with xmutil

The xmutil also provides a “bootfw_status” command which can be used to identify which image is active, which image was last booted, and what image is going to be booted on the next boot. The version information noted from bootfw_status represents the factory installed version and will not change when you update individual boot partitions.

Stand-alone FW Update & Recovery Utility

The K26 boot firmware is comprised of an “Image Selector” application, A/B MPSoC boot FW partitions, and an “Image Recovery” application. It is suggested for users to use the xmutil boot FW update tool as the primary boot FW update mechanism. If the user however gets to a state where they either want to reset the board to factory settings they can use the “Image Recovery Tool” which is a stand alone application for manually loading and configurating content of both A and B boot partitions.

The image recovery tool works in a similar manner to typical home router initial configuration with a static IP and web-server based tool which is used to directly update the A/B partitions and the persistent register states. This tool can be used to write the a factory BOOT.BIN image from the Starter Kit Boot FW table above to overwrite either image partition or both using the “Recover Image” function. The tool can also be used to modify the bootable state of each partition. If uploading a BOOT.BIN the tool will by default configure that partition to a “bootable” state.

The static IP is printed to the UART when the system is powered on with the FWUEN button pressed. For details on set-up and use of the Recovery Tool, See UG1089 for KV260 and UG1092 for KR260.

Note that Image Recovery Tool is only validated with following web-browsers:

QSPI image 20210225 -> Firefox only.

QSPI image 20210422 or later -> Firefox & Chrome

Image Recovery Application

Early KV260 Kits - QSPI Version 20210225 note:

The xmutil bootfw_update and bootfw_status utilities have a known issue with the early QSPI image (20210225) in which it will always return a “persistent registers are corrupted” message. If your board has this factory QSPI image you must use the “Image Recovery Tool” to update your Starter Kit boot firmware. To check the factory boot FW version you can directly read the version register information at address 0x2240000 via U-Boot or Linux. For reference the full QSPI image memory layout is defined below.

When using Image Recovery Tool on the boards with factory QSPI image 20210225; always upload your new boot FW as Image A by selecting the Image A radial button in the Select Image to be recovered and the Requested Boot Image sections of the Image Recovery Tool.

Boot FW QSPI Memory Map

The K26 Starter Kit boot mode pins are set for QSPI boot mode. The xmutil and Image Recovery tools provide a facility for updating one of the boot FW partitions of the QSPI device. If you desire to temporarily use a different boot mode for testing you must set the MPSoC BOOT_MODE_USER Register at 0xff5e0200 and issue a reset to override the board default.

The boot FW of the Kria Starter Kit 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 Image Recovery tools. The QSPI memory map and read/write access is defined in the following table.

Offset

Description

Access

Linux mtd

Offset

Description

Access

Linux mtd

0x0

Image Selector Application

R

0

0x80000

Image Selector Application - Fall back

R

1

0x100000

Persistent Register

R/W

2

0x120000

Persistent Register - Backup

R/W

3

0x140000

Reserved

-

4

0x200000

“Image A” - BOOT.BIN

R/W

5

0xF00000

Image Selector - Catch A

R

6

0xF80000

“Image B” - BOOT.BIN

R/W

7

0x1C80000

Image Selector - Catch B

R

8

0x1D00000

Reserved

-

9

0x1E00000

Image Recovery Application

R

10

0x2000000

Image Recovery Application - Backup

R

11

0x2200000

U-Boot Storage Variables

R/W

12

0x2220000

U-Boot Storage Variables - Backup

R/W

13

0x2240000

QSPI Image Version Information

R

14

0x2250000

Open

R/W

15

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: https://github.com/Xilinx/dfx-mgr

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”. Starting with 2022.1 Kria Linux images the default bitstream loaded is called “k26-starter-kits” has no functional PL logic but provides an EMIO mapping to the carrier card fan control pin via an EMIO. Removing this bitstream will effectively disable active fan control as the physical pin is no longer accessible to Linux. This bitstream is common to all K26 based starter kits (KV260 and KR260).

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.

Xilinx Tools Support

PetaLinux Board Support Packages

PetaLinux Board Support Packages (BSP) include pre-built images and a pre-defined configuration to rebuild the images from scratch. The Kria K26 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.

Product BSP

Description

BSP Download Link

Product BSP

Description

BSP Download Link

KR260 Starter Kit

The KR260 Starter Kit SOM BSP implements a multi-domain (staged boot process) and application agnostic OS which is used to create their own custom boot FW (BOOT.BIN) and/or Linux image reference image.

This BSP enables the same peripherals that are defined in the Vivado KR260 Starter Kit board file.

2022.1 - Xilinx download

KV260 Starter Kit

The KV260 Starter Kit SOM BSP implements a multi-domain (staged boot process) and application agnostic OS which is used to create their own custom boot FW (BOOT.BIN) and/or Linux image reference image.

This BSP enables the same peripherals that are defined in the Vivado KV260 Starter Kit board file.

2022.1 - Xilinx download

2021.1 - Xilinx download

2020.2.2 - Xilinx download

Production K26 SOM

Applies to K26C/I SOM

The K26 Production SOM is a “starter” BSP configuration for customers beginning their production carrier card design. This BSP implements only the hardware peripherals implemented on the K26 SOM itself (e.g. DDR, QSPI, eMMC), with the exception of assuming the carrier card implements PS UART1 on MIO36-37.

This BSP enables the same peripherals that are defined in the Vivado K26C and K26I SOM board files.

Note: That the production SOMs are shipped with no content on the QSPI. See UG1091 for details on setting boot mode configurations during carrier card design.

2022.1 - Xilinx download

2021.1 - Xilinx download

2020.2.2 - Xilinx download

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.

In order to use the KV260 and KR260 Starter Kit BSPs you must first install the Update 1 package from the PetaLinux 2022.1 tools download page. Instructions on how to do the upgrade are captured in the PetaLinux Update 1 release notes.

PetaLinux 2021.1 Release

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

In order to use the K26 and Starter Kit BSP you must first install the Update 1 package from the PetaLinux 2021.1 tools downloads page.

PetaLinux 2020.2.2 Release

The April 2020 SOM release is supported by a special release of the PetaLinux tool, version 2020.2.2. This version of PetaLinux is intended to only support the K26 SOM and Starter Kit. The 2020.2.2 SOM BSPs will only work with this specific version of the PetaLinux tool. The PetaLinux 2020.2.2 tool also must be installed with a full install method and not via the petalinux-upgrade function. See the PetaLinux 2020.2 downloads page for the Kria K26 Special Release information, PetaLinux installer, and support files.

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. 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. 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 and generating a WIC image, 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.

petalinux-package --boot --u-boot --dtb images/linux/u-boot.dtb –force

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

Vivado Board Support Packages

The K26 SOM is supported Vivado with three 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 2020.2.2 or later. Please make sure to use the correct released version corresponding to your chosen BSP/tool version.

  • K26C SOM - Commercial grade K26 SOM.

  • K26I SOM - Industrial grade K26 SOM.

  • KV260 Starter Kit - K26 based Starter Kit SOM with Vision AI Carrier Card connector interface.

  • KR260 Starter Kit - K26 based Starter Kit SOM with Robotics Carrier Card connector interface.

Vitis Platforms

A Vitis platform defines the physical peripherals implemented in the FPGA. As the SOM itself is application agnostic and FPGA peripherals are implemented on the carrier card, the Xilinx provided references focus on the Kria Starter Kits (e.g. KV260 or KR260). The Xilinx developed Kria Vitis platforms for all Kria platforms are provided at the Kria Vitis Platforms GitHub repository. The repository structure provides platforms for KV260 and the KR260 Starter Kit. There is also K26 “SOM only” platform that can be used on either kit as it does not implement any PL physical interfaces.

  • k26 - CC agnostic platform for K26 SOM. Does not implement any PL or CC specific physical interfaces.

  • kv260 - Platforms for the KV260 Starter Kit. The platform name describe the physical functionality that they enable on the carrier card. The KV260 carrier card uses a discrete DP/HDMI splitter thus platform names including “DP” functionally enable both DisplayPort and HDMI.

    • kv260_isp_MipiRx_vcu_DP - Implements: AP1302 ISP receive interface, VCU encode & decode functions, DisplayPort video output

    • kv260_vcuDecode_vmixDP - Implements: VCU decode only, video mixer + DisplayPort video output

    • kv260_ispMipiRx_vmixDP - Implements: AP1302 ISP receive interface, video mixer + DisplayPort video output

    • kv260_ispMipiRx_DP - Implements: AP1302 ISP receive interface, DisplayPort video output

  • kr260 - Platforms for the KR260 Starter Kit.

    • kr260_tsn_rs485pmd - Implements TSN ethernet and PMOD based RS485 interface

Kria Accelerated Applications

Accelerated Applications

KV260

The source code for the KV260 Accelerated Applications are captured in independent repositories:

KR260

The source code for the KR260 Accelerated Applications are captured in independent repositories:

SOM Utilities

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

PL & HW Repositories

Custom & Production SOM FW/SW Design Guidance

SOM 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 handling or design considerations. For details on MPSoC FW implementation see the PMU Firmware Wiki.

  • MIO31 - SHUTDOWN: The PMU has an optional input pin for an external platform shutdown request (e.g. carrier card push-button). The default mapping for this functionality in PMU FW is to PMU GPI pin MIO31.

  • MIO34 - PS_PWR_EN: The PMU controls the PS_PWR_EN 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 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.

  • MIO35 - External WD: The PMU has an optional feature for having PMU interact with an external watch-dog (WD). The default mapping for this functionality in PMU FW is to PMU GPO pin MIO35. This is implemented using the PMU FW build-time flag ENABLE_RUNTIME_EXTWDT.

  • 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.

Related Links