Boot Firmware Overview¶
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 a SD card containing the Linux kernel and Linux root filesystem (rootfs). The AMD Starter Kit carrier card hardware design sets the MPSoC boot mode to QSPI32. The SOM boots up to U-Boot using the QSPI contents and U-Boot then hand-off to the secondary boot device.
This document gives an overview to various components in the AMD Kria™ SOM boot firmware and points to source code available to get started with your implementations for your Kria SOM custom carrier card. For general information about the boot of the AMD Zynq™ MPSoC, refer to the Boot and Configuration chapter in the Zynq UltraScale+ Device Technical Reference Manual (UG1085).
The QSPI image and its boot firmware (FW) contents in SOM Starter Kits are common across all K26 starter kits.
The overall boot device definition and firmware contents are outlined in the following figure.
For advanced evaluation, you can customize the boot firmware using Yocto or the corresponding kit PetaLinux BSP. For pointers on how to generate BOOT.BIN, refer to BootFW BOOT.BIN Generation page. Yocto or PetaLinux BSP can be used to generate a new BOOT.BIN that is then loaded to the QSPI user A/B partition and custom SD card contents summarized in the following diagram:
Primary Boot Device¶
The primary boot device is a QSPI device physically located on the Kria SOM. The necessary elements are packaged in an AMD Zynq™ UltraScale+ MPSoC specific format and file captured as BOOT.BIN. The BOOT.BIN file contains the board-specific boot firmware which consists of the following elements:
FSBL: First-stage boot-loader firmware
PMU: Platform management unit firmware
SOM specific PMU guidance can be found on SOM wiki page
TF-A: Trusted Firmware with support for A-Profile Arm processors
Source code and read-only copy - bl31 used
U-Boot: Second-stage boot loader
The primary boot device provides a fail-over copy of boot firmware arranged in an A/B configuration. The A/B configuration provides a dynamic primary and secondary (last known working) image operation with corresponding update mechanisms. On boot, the system automatically boots from the defined primary image, and, if boot fails, it falls back to the previously known good boot image.
Secondary Boot Device¶
The secondary boot device on the Kria Starter Kits is a SD card. It contains the operating system image and associated application files. It also contains a superset of device trees for various board configurations and a boot script used by U-Boot to select the dynamically detected board configuration.
A/B Boot Concept¶
The Kria Starter Kits support an A/B FW update mechanism to ensure that the platform has a known good fallback in the event of an issue during the upgrade process. The A/B concept is that two copies of the software stack are maintained in the non-volatile (NV) memory, with one being the “current” image and the other being “backup”.
For illustration, say you booted until Linux using Image A.
You have the capability to update the backup image, which, in this case, is Image B. This update can be done using the bootfw_update utility from xmutils from Linux (also called Image Update). Upon updating Image B, the requested image is set to Image B, and it is marked as “Non-Bootable”. Upon reboot, Image Selector uses the following algorithm to decide which image to boot:
If both images are marked “Bootable”, Image Selector boots the requested image.
If both images are marked “Non Bootable”, this state implies the FW is in a bad state because neither of the images are verified as booting until Linux, and the system then boots the Image Selector application Image Recovery.
NOTE This state should not occur if using the normal A/B update mechanisms.
If the requested image is non-bootable and the last booted image is bootable, it implies the requested image was updated during the previous boot and hence that image, Image B in the example, is selected for boot.
If the requested image is non-bootable and the last booted is non-bootable, it implies the newly updated Image B failed to boot. In this case, Image selector falls back to the known good image, which is Image A and Image A boots.
ImgSel flow based on the QSPI persistent registers is shown in the following figure.
Kria SOM A/B updates builds on top of the MPSoC multi-boot functionality and abstracts the A/B concept with two pre-defined boot partitions. The boot.bin A/B partitions are maintained and laid out in the QSPI primary boot device. The QSPI has a dedicated region for maintaining persistent boot state registers and the associated boot image offsets.
To work within the functionality of the MPSoC CSU ROM, the Image Selector application that is launched at power-on reset (POR) to select which boot.bin image is used by passing a different offset to the CSU multi-boot register. The ImgSel application can be copied after each of the boot image partitions at the a 32 KB boundary so if the boot fails, the CSU ROM functionality immediately loads ImgSel as the next discovered image. This allows ImgSel to provide the failure recovery mechanism to point back to the last bootable image based on the state information in the A/B Persistent Register.
To see which image was selected for booting, read the MultiBootOffset value from FSBL prints, for example:
Zynq MP First Stage Boot Loader
Release 2023.1 May 1 2023 - 00:38:12
MultiBootOffset: 0x40
Reset Mode : System Reset
If MultiBootOffset is 0x40, Image A was selected. If MultiBootOffset is 0x1f0, then Image B was selected.
Boot FW QSPI Memory Map¶
The boot FW of the Kria Starter Kits is pre-loaded at time of 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 you can primarily focus on OS level updates and late bound loading of bitstreams. Sectors of the QSPI device on Kria Starter Kits are locked during production to prevent accidental overwrite in customer systems, with the only sectors that are read/write are the A and B boot partitions by the xmutil Image Update and Image Recovery tools.
NOTE: The Production SOM (that is to be used with custom CC) does not have locked or pre-loaded QSPI.
The following is QSPI memory map used for Kira SOM Starter Kits:
| Offset (hex) | Size (hex) | Sector Access | Description | Linux mtd |
|---|---|---|---|---|
| 0x00000000 | 0x80000 | R | Image Selector Application | 0 |
| 0x00080000 | 0x80000 | R | Image Selector Application Golden | 1 |
| 0x00100000 | 0x20000 | R/W | Image Selector registers | 2 |
| 0x00120000 | 0x20000 | R/W | Image Selector register backup | 3 |
| 0x00140000 | 0xC0000 | - | Reserved | 4 |
| 0x00200000 | 0x300000 | R/W | Image A ( BOOT.BIN containing FSBL, PMU, ATF, U-Boot) | 5 |
| 0x00500000 | 0xA00000 | R/W | Space for larger images (PL - 8MB, RPU - 2MB) | 5 |
| 0x00F00000 | 0x80000 | R | ImgSel Image A Catch (ImgSel application) | 6 |
| 0x00F80000 | 0x300000 | R/W | Image B ( BOOT.BIN containing FSBL, PMU, ATF, U-Boot) | 7 |
| 0x01280000 | 0xA00000 | R/W | Space for larger images (PL - 8MB, RPU - 2MB) | 7 |
| 0x01C80000 | 0x80000 | R | ImgSel Image B Catch (ImgSel application) | 8 |
| 0x01D00000 | 0x100000 | - | reserved | 9 |
| 0x01E00000 | 0x200000 | R | Image Recovery Application | 10 |
| 0x02000000 | 0x200000 | R | Image Recovery Application backup | 11 |
| 0x02200000 | 0x20000 | R/W | U-Boot storage variables | 12 |
| 0x02220000 | 0x20000 | R/W | U-Boot storage variables backup | 13 |
| 0x02240000 | 0x40000 | R | QSPI Image Version Information* | 14 |
| 0x02280000 | 0x20000 | R/W | Secure OS storage | 15 |
| 0x022A0000 | 0x1d60000 | R/W | End Address (User) | 16 |
* QSPI Image Version Information Example: XilinxSom_QspiImage_v1.0_20201030 Last 32Bytes: HashValue Hash Algo: SHA256 It is only 256 bytes but has to be 64 KB aligned. Therefore, the size is 0x10000.
Starting from 2022.2, Yocto can generate QSPI images for Starter Kits. Information can be found in QSPI Stitching page.
Image Selector Registers¶
The following table shows the contents of image selector registers at offset 0x100000:
| Offset | Register | Description | Default Value for SOM Manufacturing Image |
|---|---|---|---|
| 0x0 | Identification String | “ABUM” – A/B Update Mechanism | 0x4D554241 |
| 0x4 | Version | 0x1 | 0x00000001 |
| 0x8 | Length | 4 – No of registers present (not including the first 4) | 0x00000004 |
| 0xC | Checksum | SUM of all words excluding checksum | 0xAEB1BDB9 |
| 0x10 | Persistent State register | See table below | 0x01010000 |
| 0x14 | Image A offset | CSU multi-boot address offset of "Image A". Must correspond to 32 KB boundary. | 0x00200000 |
| 0x18 | Image B offset | CSU multi-boot address offset of "Image B". Must correspond to 32 KB boundary | 0x00F80000 |
| 0x1C | Recovery offset | CSU multi-boot address offset of "Recovery Image". Must correspond to 32 KB boundary. | 0x01E00000 |
Persistent Register¶
The following table shows the encoding for persistent register. Default value for SOM manufacturing image: 0x01010000
| Bit width | Field | Type | Description |
|---|---|---|---|
| 7:0 | Last Image Booted | R | 0 - Image A, 1 - Image B |
| 15:8 | Requested Boot Image | RW | 0 - Image A, 1 - Image B |
| 23:16 | Image B Bootable | RW | 0 - Not bootable, 1 - Bootable |
| 31:24 | Image A Bootable | RW | 0 - Not bootable, 1 - Bootable |
Boot Image Applications¶
The following applications uses or updates Image A/B and/or persistent registers. All three applications are independent and can work standalone with no dependencies across the three applications.
For more information on how to uses the three applications, refer to Kria SOM wiki and the Board Reset, Firmware Update, Recovery chapter in the Kria KV260 Vision AI Starter Kit User Guide (UG1089).
Image Selector Application¶
The Image Selector (ImgSel) application is a small baremetal application running out of OCM after a POR/SRST to select the OS boot image. It reads the persistent register to decide which image to boot from in the QSPI memory map.
For more details on this application, refer to the Image Selector page.
Image Update¶
The Image Update Linux application is a function being called by xmutil that updates Image A or Image B at runtime. It is included in the Kria Starter Kit Linux root file system. When called to update Image A or Image B, the Image Update Linux application will also update the persistent register.
For information on how to use Image UpdateRead, refer to Boot FW via xmutil section of Kria SOM wiki. Visit the linux image update repository to see the source code.
Image Recovery Application¶
The Image Recovery application is a baremetal application that uses a web-browser-based user interface. It is invoked when the FW-update button is pressed at power-on, or when both Image A and Image B becomes un-bootable. It can be used to directly update the A/B images and persistent register states.
For more details on this application, refer to the Image Recovery page.
U-Boot¶
U-Boot provides the functionality for the hand-off between the primary boot device and the secondary boot device. It will select the appropriate boot devices, load the Linux kernel, select Linux device tree based on the detected hardware configuration, and then boot Linux.
U-Boot is an open source Universal Boot Loader that is frequently used in the Linux community. AMD provides a Git tree located at GitHub which includes (https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842223/U-boot). U-Boot for SOM has been configured to support dynamic booting on different Starter Kits using MPSoC PMU configuration objects.
For more details on dynamic carrier card configuration in Kria Starter Kits, refer to PMU configuration objects and U-Boot handoff.
QSPI Component and QSPI Update¶
QSPI used in a commercial grade SOM is MT25QU512ABB8E12-0SIT. The QSPI used in I-grade SOM is MT25QU512ABB8E12-0AAT. The QSPI has locking functionality. For details, refer to linked datasheets on Micron.
If you are developing on AMD released Starter Kits, the QSPI image is locked and the only section that should need an update is the Image A/B section along with the persistent registers.
However, if you are developing your own carrier cards, the production SOM’s QSPI section is not locked. The entire QSPI can be customized to meet your boot firmware requirements for your production designs.
License¶
Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License.
You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Copyright© 2023-2025 Advanced Micro Devices, Inc