Image Selector (ImgSel) Utility

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.

Device Family

GitHub Source Code

Device Family

GitHub Source Code

Zynq UltraScale+ MPSoC

https://github.com/Xilinx/embeddedsw/tree/master/lib/sw_apps/imgsel

Versal Adaptive SoC

Source Code Coming Soon

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

Board

Multi-Boot Value

Active Image Filename

Golden Image Filename

Board

Multi-Boot Value

Active Image Filename

Golden Image Filename

ZCU102

1020

boot1020.bin

boot1021.bin

ZCU104

1040

boot1040.bin

boot1041.bin

ZCU106

1060

boot1060.bin

boot1061.bin

VCK190

1900

boot1900.bin

boot1901.bin

VMK180

1800

boot1800.bin

boot1801.bin

VPK180

1810

boot1810.bin

boot.1811.bin

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

EEPROM Offset (Hex)

Field Name

Field Data Type

Field Length (bytes)

Field Example (ASCII)

Field Example (Hex)

EEPROM Offset (Hex)

Field Name

Field Data Type

Field Length (bytes)

Field Example (ASCII)

Field Example (Hex)

0x00

Board Serial Number

ASCII

32

881437311925-10426

0x3838313433373331313932352D3130343236

0x20

Ethernet MAC ID

Binary

6

10203040506

0x10203040506

0xD0

Board Name

ASCII

16

ZCU102 (5 spaces)

0x5a43553130322020202020

0xE0

Board Revision

ASCII

6

1.1 (2 spaces)

0x312E31

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)

Record Area

Record Type

Record Start

Record End

Record Area

Record Type

Record Start

Record End

Common Header

IPMI Standard

0x00

0x07

Board Info Area

IPMI Standard

0x08

0x67

DC Load MultiRecord

IPMI Standard

0x68

0x79

SOM MAC Addr MultiRecord

IPMI OEM Record

0x7A

0x88

SOM Memory Config MultiRecord

IPMI OEM Record

0x9B

0xF6

Version 2 (KR260 SOM)

Record Area

Record Type

Record Start

Record End

Record Area

Record Type

Record Start

Record End

Common Header

IPMI Standard, refer to table 8-1 in IPMI Spec

0x00

0x07

Board Info Area

IPMI Standard, refer to table 11-1 in IPMI Spec

0x08

0x67

DC Load MultiRecord

IPMI Standard, refer to table 16-1 and 18-4 in IPMI Spec

0x68

0x79

SOM MAC Addr MultiRecord

IPMI OEM Record, refer to table in MAC Addr MultiRecords

0x7A

0x88

SOM Memory Config MultiRecord

IPMI OEM Record, refer to table in Memory Config MultiRecord

0x89

0xE4

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 I2C address of the EEPROM and other relevant information.

Related Links

© Copyright 2019 - 2022 Xilinx Inc. Privacy Policy