This page contains specification and architecture information for the AMD Embedded Development Framework (EDF), which is applicable to all supported evaluation boards and custom development flows.

Table of Contents

General Specifications

This section provides common sections of the AMD Embedded Development Framework (EDF) specification, which are implemented across multiple platforms and device families. Some common specifications might be superseded based on device or evaluation board feature sets. See the device and board specific specification pages for more information.

Boot Architecture for AMD Evaluation boards

For AMD evaluation boards, a common boot architecture has been adopted, which is implemented in the BSPs and prebuilt disk images provided.

The boot architecture includes support for Arm SystemReady™ IR and Trusted Firmware-A Platform Security Architecture Firmware Update (PSA FWU).

• Platforms are not certified; this is a reference implementation that can be used on a pathway to certification.

Multi-Stage Boot with Deferred PL Load* - Default Boot Architecture

This is the default boot flow for BSP and prebuilt images for AMD evaluation boards, supporting the latest AMD adaptive SoC and FPGA devices and AMD EDF development flows.

Open

Stage 1 - Primary boot device: OSPI / QSPI - AMD EDF boot firmware with image select and recovery

• AMD EDF boot firmware - See https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586143/Common+Specifications#Boot-Firmware-overview for detailed information

  • Identifies the board from the EEPROM

  • Loads board specific .pdi

  • Loads TF-A

• TF-A runs and loads U-Boot using the device-specific device tree (identified from EEPROM)

• U-boot loads and boots a Linux® disk image from the secondary boot device

  • Initial version of AMD EDF (2025.1) - Distro boot

  • Support for SystemReady (2025.2 and onwards) - UEFI boot

Stage 2 - Secondary boot device: SDMMC / USB / UFS - Common** Linux disk image

• The Linux disk image will boot to a console - programmable logic (PL) not loaded

• PL can be loaded from the Linux user space - TODO: fill in <refs> below

  • The Linux disk image contains PL firmware payloads - See <ref to payloads>

  • See <ref> for command to load, re-load, or automate loading of PL payloads

Single-Stage Boot with Deferred PL Load - Optional Boot Flow

A single-stage boot flow is also supported and is used for some AMD EDF Linux BSPs and prebuilt Linux disk images.

Open

Stage 1 - Primary boot device: SD card / UFS / USB

• Boot.pdi is loaded from the primary boot device

• TF-A is loaded and runs; TF-A loads U-Boot using a board-specific device tree.

• U-Boot runs, and then boots the Linux disk image (Common** Linux disk image) from the primary boot device using a board-specific device tree

  • Initial version of AMD EDF (2025.1) - Distro boot

  • Support for SystemReady (2025.2 and onwards) - UEFI boot

• The Linux disk image will boot to a console - PL not loaded

• PL can be loaded from the Linux user space - TODO: add <ref> below

  • The Linux disk image contains PL firmware payloads - See <ref to payloads>

  • See https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3258155011/Discovery+and+Evaluation+AMD+Versal+Device+Portfolio#Loading-the-pre-built-Programable-Logic-(PL)-firmware-BRAM-GPIO-UART-demo-(Vivado-design) for commands to load, re-load, or automate loading of PL payloads

*AMD adaptive SoCs and FPGA with support for Segmented Configuration or deferred PL load: AMD Versal™ portfolio, AMD Zynq™ UltraScale+™ MPSoC.

** Common Linux disk image across compatible AMD adaptive SoC and FPGA, typically across device series.

Initial Programming of Primary Boot Device

System Controller enabled evaluation boards

• System Controller can be used to program the OSPI / QSPI flash used by the target device.

  • See System Controller WIKI evaluation board user guide for more information https://xilinx-wiki.atlassian.net/wiki/x/AYCGhw

• AMD Vivado Design Suite can also be used to program OSPI / QSPI flash used by the target device, see the relevant Vivado documentation or evaluation board user guide for more information.

Boot Firmware overview

The AMD EDF boot firmware is an evolution of the Image Selector Application used on AMD Kria™ SoM, and is normally pre-loaded on AMD evaluation boards, but may need to be manually loaded for Early Access (EA) valuation boards or evaluation boards supported by AMD-EDF but which were originally released prior to 2025.

The boot firmware includes support for:

• Multiple boot images (boot.pdi)

• Fallback and recovery using an A-B scheme by default.

• Arm SystemReady™ IR and Trusted Firmware-A Platform Security Architecture Firmware Update (PSA FWU)

  • Platforms are not certified, this is a reference implementation that could be used on a pathway to certification.

• Flash management from Linux user space

The main components within the AMD EDF Boot firmware are outlined below

Image Selector Application

The Image Selector application boots on a cold reset of the device (POR_B) and acts as an platform controller selecting the "A" or "B" boot image from the firmware store implemented elsewhere in the primary boot non volatile memory device.

In the context of the Platform Security Firmware Update for the A-profile Arm^® Architecture specification, this is represented by the "BMC/Immutable" component of the boot flow shown in the figure below. 

The Image Selectors behavior is data driven, based on the information available in the metadata fields of its primary boot device. 

Open

The Image Selector app also implements a function for initiating the Image Recovery application which can be initiated by the user through physical interaction with the platform at time of POR_B. This is implemented with a MIO-GPIO accessible pushbutton where available.

The Image Selector in Versal devices stores soft reset data such as SystemReady-DT boot counter in the PMC Persistent Global General Storage registers. These "user" facing registers are documented at this public Wiki.

The Image Selector uses PERS_GLOB_GEN_STORAGE4 with the following SystemReady-DT information consolidated within the register, aligned by byte.

• MSB = "Magic" number - Unique value to help validate correct register read, Value = 0x1D

• MSB-1 = Boot Counter

• MSB-2 = Image Selected, Value = 0x0, "A", 0x1 "B"

• MSB-3 = Rollback Counter

Image Recovery Application

The Image Recovery application simplifies the process for users to update the primary and secondary boot devices without requiring AMD-Xilinx specific tools. It supports the "Recovery Mode" called out in the Arm Platform Security Firmware Update for the A-profile Arm Architecture specification, and supports update of "A", "B" and the corresponding "Metadata" fields in the primary boot memory device. 

The Image Recovery Application is a Linux-based web application that runs on the target and supports

• Updating boot firmware (OSPI / QSPI) content and boot slots (A / B)

• Updating disk images on secondary boot devices (SD, USB, UFS)

The web interface operates using an IP address (e.g., 10.10.70.2:8080), which is displayed on the UART console output of the target when image recovery boot mode is triggered

• Image recovery boot mode is triggered by pressing the recovery mode push button on the Evaluation board

• It can also be triggered via a register write from u-boot or via XRDB (JTAG) for boards without a recovery mode button.

Upon launching the web interface using the IP address shown on the UART console, a page will open, providing basic information about the hardware:

Open

To update the Boot Firmware or Linux image using Ethernet Recovery, click the Browse button and select the desired file.

• To update the Boot Image, select the boot.bin file, toggle the ‘Boot Image’ option, and click ‘Upload’.

• To update the disk image, select the wic/wic.xz file, toggle the ‘Wic Image’ option, and click ‘Upload’.

Upon successful update, you will see the message displayed below.

Open

See the boot firmware Linux utility for information on how to update and manage the images in the boot flash (Primary Boot device) from Linux user space (normal runtime image)

Boot Firmware Image Update Utility (fwupdate tool)

The image update utility is a Linux utility integrated within the Linux OS capable of interfacing with the primary boot device (QSPI/OSPI) and doing the following:

• Updating the non-active A or B partition, modifying the necessary meta-data, and preparing the system for a reboot in which it switches to the new firmware (FW) image (boot.pdi). This functionality is referred to as the "Update Client" in the Arm FW Update guide.

• Inquiring on the status of the boot device FW contents - To follow

The Boot Firmware Image Update Utility checks the GUID of a given FW before attempting updates in order to ensure that the FW capsule is aligned with the hardware (HW) target it is about to attempt an update on. The board GUID is located in the Board-ID EEPROM on AMD Evaluation boards.

fwupdtool tool

The Linux firmware update system, fwupdtool, utilizes .cab files as standard containers for firmware update metadata and binaries. These CAB files are meticulously signed and organized, enabling fwupdtool to verify their integrity and apply updates securely.

Pre-requisites

• The system must be running EDF boot firmware and be configured for multi-state boot

• The secondary boot device must be running an image based on EDF, with EFI partitions present

To utilize the first partition of an SD/USB drive with fwupdtool, ensure that it is formatted as an EFI type.

fwupdtool get-devices

The fwupdtool get-devices command is utilized to display all devices recognized by fwupdtool on your system that may be eligible for firmware updates.

It will print device metadata, such as:

• Device name & GUID

• Firmware version

• Vendor

• Status (e.g., updatable, not updatable)

• Flags (e.g., internal, requires reboot)

Generating Capsule files (cab) for use with fwupdate

Capsule files (cab) for use with fwupdate are generated from the EDF Yocto Project based build environment using the uefi-capsule recipe

For more details see LINK TO DEVOPMENT FLOWS

Installing the CAB files with fwupdate

The CAB file is installed with the fwupdate tool

During a reboot you can view the logs of the capsule file being applied, and the switch to the Trail state.

Accepting the update and existing Trial state

If boot is successful the capsule update must be accepted, the Trial State must be exited, and a reboot should be initiated

During the reboot, you can view the logs of the acceptance capsule file being applied and the automatic reboot.

Image Selector output at boot time (EDF boot firmware)

The Image Selector log file will displays the status at boot time

active_index: 0 - indicates bank number A,   1 - indicates bank number B

bank_state : FC - Accepted, FE - Not accepted

Image Type Guid: CB27E54D-8F3A-4C77-8A72-1C76D2D4E938     GUID specific to board

The PLM output at boot time

The PLM UART output will also show status and which image bank (A/B) is in use

U-boot output at boot time

The u-boot UART output will also show Image status

Known issues in EDF 25.05.1

• It is essential to always specify the FWUPD_UEFI_ESP_PATH=/boot/efi when executing the fwupdtool.

Known issues in EDF 25.11

u-boot is not currently able to install capsule using the auto-generated boot entries (“mmc0”, “mmc1”, “usb0”, etc.) so it is necessary to manually add a boot entry to the UEFI menu pointing to the device that contains the capsule you wish to install. This entry can be removed once the update has completed if desired. Below is an example of adding an entry to u-boot for the purposes of capsule install and triggering the install. This entry assumes that the capsule is available in the EFI System Partition of the first MMC device, hence “mmc 0:1”.

OSPI/QSPI Memory Layout - Common Specification

The OSPI Memory Map bellow illustrates the high-level structure of the memory layout specifically designed to be consistent across multiple memory devices and AMD Evaluation boards.

Each region in the memory map has a designated functionality, as indicated in the "R or R/W" column. This column depicts whether the sector is read-only (R) or both read and write (R/W). Notably, some platforms might lock read-only sectors utilizing the hardware-level lock feature built into QSPI/OSPI systems.

By providing a unified framework for memory layouts, the OSPI (Flash) Memory Map simplifies the process of adapting to different memory devices and ensures a seamless experience across multiple platforms.

Board-ID EEPROM

AMD Evaluation boards with support for AMD-EDF boot flows contain a Board-ID EEPROM, which includes a unique device identifier used for the UEFI Capsule Update GUID firmware identifier or "image type" that is embedded as part of the capsule header.

The following table provides pre-allocation of GUIDs based on target platforms for the Basecamp FW alignment:

Over The Air (OTA) Firmware (FW) Deployment - To follow

AMD-EDF also contains support for OTA FW update. New FW update capsules can be deployed to AMD targets via Linux packages (*.deb, *.rpm) aligned with the platforms target Linux distribution. Package names will be aligned with the platform name, and package revision information will be updated and incrementally aligned with the FW image revision to allow "apt update" like operations to grab new FW revisions automatically. 

Trusted Platform Module (TPM) - To follow

AMD-EDF boot firmware is architected to support the concept and implementation of "measured boot", where a boot time measurement of each element FW boot time configuration sequence can be stored.

This functionality is due to be added in a future release.

PS common minimum specification

This specification has a strong device specific element, also see the PS sections of https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586239

The default PS configuration aligned with the board defines fixed MIO, clocks, and enabling of clock frequencies enabled by the speed grade of the target device. 

• MIO Controller - All MIO controllers (for example, I2C, SPI) associated with fixed peripherals of the platform will be enabled and configured based on the hardware board design.

• MIO I/O Configurations - All MIO default I/O controls (for example,. pull-ups, slew rates) will be based on the hardware platform design. 

• Secondary Boot - Should be set to "None". The Vivado feature is for a PLM PDI load from the secondary device, but in the context of Basecamp, the secondary boot device for boot Linux is managed by U-Boot and not PLM. 

The minimal requirements for PS connected peripherals and settings are as follows and also reflect minimal peripheral requirements for evaluation boards:

• Boot Flash

• Storage Flash

• Boot mode - To support the boot architecture https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586143/Common+Specifications#Boot-Architecture-for-AMD-Evaluation-boards

• UART (multiple if available)

• Ethernet

• MIO Controllers

  • I2C - Connected to EPPROM for board ID

  • SPI

• GPIO to be connected to PL

• IPI settings - To support OpenAmp and Xen implementations

  • See https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586239

Embedded common platform Configurable Example Design (CED)

The embedded common platform CED is mapped to all supported evaluation boards and enforces common settings and PS minimum specifications to provide a unified starting point for platforms, reference designs and BSP creation. A part based flow uses the same for custom board development.

The CED implements the PS common minimum specification, and other items to support the EDF common boot architecture, using support in the AMD Vivado™ Design Suite for segmented configuration. This allows for creation of multiple compatible PL payloads that can be loaded at runtime onto a single initial boot image.

• The files needed to build compatible designs are included in the CED package in the AMD Vivado™ Design Suite installation.

When the CED is mapped to an Evaluation board, the minimum requirements are extended to ensure that all PS enabled IP supported by the evaluation board are supported.

See https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586284

CED Hierarchy

The CED flow also includes hierarchy from AMD Vivado™ Design Suite version 2025.1, and allows users to build alternative configurations or sub-platforms from a single CED. One CED can generate multiple alternative platform configurations or designs with aligned settings, based on user selections.

The picture below tries to illustrate this hierarchy

• Common PS settings + multiple alternate PL Payloads

Open

Minimal PL payload (default)

This a deliberately simplistic PL design, it gives enough functionality to prove the PL is available.

This PL Payload is also shipped as part of the common disk image, and captured as the "default" PL firmware via dfx-mgr during the Linux boot process.

PL Payload content

• AXI-BRAM

  • To support simple read/write scratchpad between the PL and the PS. It shall be configured with a single BRAM utilization which acts as a memory scratchpad.

• AXI-GPIO

  • The following are the mix of I/O that will be prioritized as a mix of input and output functions:

    • PL user LEDs

    • PL push button

    • PL PMOD interface

  • See https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586284

Open

EDF prebuilt Yocto machine definitions

List of Yocto pre-built Machine names for supported AMD evaluation boards