This page provides an overview of the Image Selector tool that is used to control the boot process for the Certified Ubuntu image.

Table of Contents

Introduction

The Image Selector (ImgSel) utility is a lightweight application that runs as the first payload in the boot process of an AMD Adaptive Computing evaluation board. The utility reads board-level metadata to determine which board it is running on, configures the device to use the correct primary payload, and then reboots the board into the selected payload.

On evaluation boards based around Zynq UltraScale+ MPSoC devices, the ImgSel utility is a minimized and optimized version of the First Stage Boot Loader (FSBL). On Versal-based boards, the ImgSel utility is an optimized version of the Platform Loader & Manager (PLM) software.

The source code for the ImgSel utility can be found on the public AMD-Xilinx GitHub.

Overview of Operation

The ImgSel utility makes use of several key hardware capabilities found in the Zynq UltraScale+ and Versal Adaptive SoC device families. Chief among these capabilities is the multiboot capability. The multi-boot feature combines the Golden Image Search and Fallback capabilities along with a dedicated hardware register to allow the user to specify a specific image (filename or flash offset) to be loaded during the next boot.

For Zynq UltraScale+ devices, this capability is described in the Zynq UltraScale+ Technical Reference Manual (UG1085) here. For Versal Adaptive SoC devices, this capability is described in the Versal Technical Reference Manual (AM011) here.

The ImgSel utility assumes that it will be loaded as the first binary executable payload in a bootable image. For file system-based boot such as from SD card, this file should be called BOOT.BIN. When the ImgSel utility executes, it is hard-coded to look for an I²C EEPROM device at a specific address. If it finds the EEPROM device, it will read the board-level metadata to determine which board it is running on.

Once the ImgSel utility has determined its host board, it will set the device multi-boot register to correspond to a specific value that corresponds to a BOOT.BIN that contains a numeric suffix specific to that board. Once the multi-boot register has been set, the ImgSel utility will execute a soft reset (SRST) of the board. During the reboot process, the multi-boot register is used to specify which specific BOOT.BIN (with accompanying suffix) file should be used to boot rather than the default BOOT.BIN file (without a suffix). If a BOOT.BIN file is not found with that suffix, the device Boot ROM will begin searching numerically for a BOOT.BIN with the next highest suffix.

For example, if the multi-boot register is set to a value of “100”, the device Boot ROM will look for a file called BOOT0100.BIN during its next warm boot. If it fails to find this file, it will start searching for files called BOOT0101.BIN, BOOT0102.BIN, and so forth. The ImgSel-based boot process assumes that a "Golden Image" will always be present with a higher numeric suffix that the boot process can "fail into" should the target image be unavailable.

The table below summarizes the supported boards, corresponding numeric suffixes, and the filename of the golden fallback image.

The Certified Ubuntu images utilize ImgSel-based boot extensively. The boot process for this image is described in detail here.

Board-Level Metadata (FRU Data)

Regardless of the device family, the board-level metadata is stored in an attached I²C EEPROM device. While it is possible for the metadata to contain much more data than ImgSel requires, the minimum data required are as follows:

• Board Name

• Board Revision

Zynq UltraScale+ MPSoC Boards (ZCU10x Boards)

The traditional Zynq UltraScale+ MPSoC boards in the ZCU10x family use a bespoke EEPROM data format. The metadata is stored in the layout described in the table below.

Kria and Versal Adaptive SoC Boards

Kria SOM and Versal Adaptive SoC boards utilize the standard IPMI Information Storage Definition 1.0 format. The mapping of this data is described in detail on the Kria SOM EEPROM github.io page. This general format of this data is the same for both Kria SOM and Versal Adaptive SoC boards.

In general, Kria SOM boards follow the basic layout shown below.

Version 1 (K26 production SOM, KV260 SOM)

Version 2 (KR260 SOM)

For users designing their own Kria SOM carrier board, please consult the Kria SOM EEPROM Design Guide on github.io. This page details information such as the expected I²C address of the EEPROM and other relevant information.

Related Links

• IPMI FRU Information Definition 1.0 - https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/ipmi-platform-mgt-fru-info-storage-def-v1-0-rev-1-3-spec-update.pdf

• Kria EEPROM-gen Utility - https://github.com/Xilinx/kria-eeprom-gen