/
Development Flows - How it all works

Development Flows - How it all works

This page contains information on the development flows supported by the AMD Embedded Development Framework (EDF) organized by developer persona, common development tasks, and tips and tricks. Detailed step-by-step walkthroughs and examples are available in the Getting Started pages.

Table of Contents

 

Introduction

The following sections walk a user through AMD EDF, moving through the development persona shown in the picture below, from initial board setup and exploration using a prebuilt image, to on target development, deployment options, and custom flows.

We have used persona to help illustrate what can be done using prebuilt images with minimal re-compile, and the more advanced flows further along the development pathway where software and hardware are more custom.

Discovery and Evaluation

The first step of the journey is switching on the board and seeing it work; exploration can then begin using provided reference designs. Intent - Get an evaluation board up and running quickly, and enable users to explore both hardware and software reference designs.

AMD EDF provides prebuilt binary disk images for AMD evaluation boards with compatible reference payloads and examples.

 

These flows are enabled by the adoption of a Segmentation Configuration based boot flow with deferred programmable logic (PL) load and common specifications stored in an AMD Vivado™ Configurable Example Design (CED) - the Embedded Common Platform.

  • Multiple compatible images can be generated in the Vivado Design Suite for a board—and be applicable to a range of boards.

 

The specifications used in EDF are split between:

https://xilinx-wiki.atlassian.net/wiki/x/HwLAwQ

  • Items common across all device families and boards

https://xilinx-wiki.atlassian.net/wiki/x/fwLAwQ

  • Items common to a device family or portfolio

https://xilinx-wiki.atlassian.net/wiki/x/rALAwQ

  • Items specific to an evaluation board

 

Embedded Common Platform CED and Sub Platforms

The Embedded Common Platform for Vivado Configurable Example Designs (CED) holds the common specifications for the evaluation board experience. It is the starting point for development pathways and advanced designs by users and AMD. AMD reference designs and flows use the Embedded Common Platform as a starting point. The common base platform implementation ensures that the PL designs can be loaded subsequent to the initial Linux boot.

  • Common entry point from the Vivado Design Suite CED menu.

  • Segmented configuration enabled by default if supported by the target device.

  • Default and common PL payload / design - Deliberately simplistic and focused on enabling streamlined customer workflows and simplified testing procedures.

  • The default PL payload (bitstream) is included in EDF disk images and captured as "default" via dfx-mgr during the Linux boot process.

The CED is mapped to different boards. It takes into account board-specific connectivity and implementing distinct connections and constraints to cater to the particular physical I/O of each board.

CED Hierarchy

The embedded common platform CED is a common entry point from the Vivado CED menu. It contains a common processing system (PS) + NoC implementation, and is configurable at build time in Vivado with alternative PL / IP payloads. There are board- and part-based CED to support evaluation boards and chip-down flows.

Example:

image-2025-3-25_10-45-22-1.png

Next Steps

Try it out on your evaluation board - Evaluation board based walkthrough tutorials for the evaluation and discovery phase - Get your board up and running and explore:

https://xilinx-wiki.atlassian.net/wiki/x/A4Azwg

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3258155011/Discovery+and+Evaluation+AMD+Versal+Device+Portfolio#System-Controller-Enabled-Evaluation-Boards---System-Controller-Firmware-Update - Updating the onboard System Controller

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3258155011/Discovery+and+Evaluation+AMD+Versal+Device+Portfolio#How-to-boot-a-board-using-the-pre-built-images:-Multi-stage-boot-(QSPI-/-OSPI--%3E-SD/UFS)---Setup

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3258155011/Discovery+and+Evaluation+AMD+Versal+Device+Portfolio#How-to-Boot-a-Board-Using-the-Pre-built-Images:-Single-Stage-Boot-SD-Mode---Setup

Image Recovery Application - How to use the built in Image Recovery and Selection support

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

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3265036298/Discovery+and+Evaluation+AMD+ZynqMP+device+portfolio#How-to-boot-a-board-using-the-pre-built-Images%3A-SD-Boot

 

More information on the EDF Boot architecture - https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586143/Common+Specifications#Boot-Architecture-for-AMD-Evaluation-boards

More information on the CED implementation or settings - See relevant sections of the common, device, and board-specific specifications.

https://xilinx-wiki.atlassian.net/wiki/x/HwLAwQ

https://xilinx-wiki.atlassian.net/wiki/x/fwLAwQ

https://xilinx-wiki.atlassian.net/wiki/x/rALAwQ

 

Application Development and Deployment

Applications targeting adaptive SoCs typically consist of hardware and software components. Different aspects of application development can be performed on target or on a host PC using a cross-development SDK environment.

Using a hybrid approach and re-using compiled components and the running system allows the user to quickly test, debug, and iterate over changes. EDF adopts this with development flows that re-use the prebuilt disk images and the runtime system. For example:

  • Using the prebuilt or run time Linux image with AMD Vitis™ tool flows: Transfer payloads to the existing running system rather than creating a new system image.

  • Using Segmented Configuration to deploy a new PL image to the running system for test rather than re-build and reboot.

When the application is stable and ready for release, the Yocto Project™ build system provides a way to integrate the application build and to package applications for production deployment. This may even include the use of a package stream to release items over the air.

Hardware components include PL and/or AI Engine payloads are typically provided as PDI and/or xclbin. In Linux, hardware payloads are packaged as firmware binaries (e.g., PDI with device tree binary overlay (dtbo)).

Software components include device drivers (e.g., Linux kernel modules) and software libraries / applications (Linux user-space).

 

Overview Diagram of Application Flows

 

app_dev_flow.jpg

 


EDF splits the Development and Deployment persona into the following:

Software Application Development on Target

Using the prebuilt EDF Linux disk images for AMD evaluation boards for on-target development, which is convenient because native compilers and tools can be used, with a workflow most developers are used to and is similar to native x86 development on a workstation. You can install a rich set of dev packages from the package feed and use familiar build systems like make, autotools, cmake, or meson without having to set up a cross-development environment.

Next steps

Try it out on your evaluation board - Evaluation board based walkthrough tutorials all phases

Software Application Development on Target

Package Management using RPM

Accessing the package feed without a on line network connection

Toolchain installation

Software application development

Kernel module development

Development inside container

Software Application Development using SDK

Using the EDF SDK for cross-development on an x86 host, and using the prebuilt EDF Linux disk images for testing, which is useful when a user doesn't have direct access to a board for on-target development. Depending on the project, using an SDK can speed up the build task compared to building on-target. The downside is that the content of the SDK is fixed, and it is not possible to install additional dev packages or utilities into an existing SDK—whereas on target, packages can be installed from the package feed.

Next steps

Try it out on your evaluation board - Evaluation board based walkthrough tutorials all phases

Software Application Development using SDK

SDK installation

Software application development

Kernel module development

QEMU based development

Hardware Application Development

Traditional RTL / FPGA development to add custom functionality, but via Segmented Configuration to enable generation of PL images compatible with a base design or the EDF prebuilt images. This enables different payload (PL or other) to be loaded or re-loaded from Linux at runtime when running the prebuilt EDF Linux disk image (or a user generate disk image), speeding up development (test on running system) and enabling dynamic payload management on deployed systems with Linux / U-boot as the system manager (e.g., version management, fallback, recovery).

 

These flows also make use of the Software Hardware Exchange Loop (SHEL) flow to exchange hardware and software configuration data among various open-source and proprietary tools. This includes the Yocto Project™, Zephyr West, AMD Vitis™ Unified Software Platform, and AMD Vivado™ Design Suite. For more information on the SHEL flow see https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3164209163

 

For more information on Segmented Configuration support in the Yocto Project™ and packaging, see https://xilinx-wiki.atlassian.net/wiki/x/4QLAwQ and the relevant sections of the Getting Started walkthrough pages that have examples of packaging firmware.

Next steps

Try it out on your evaluation board - Evaluation board based walkthrough tutorials all phases

Hardware Application Development

PL design / payload content:

Maintaining and checking compatibility of a generated PL firmware application (...

Building the compatible PL design / payload

 

Application Deployment using Yocto Recipes

Once applications have been created the Yocto Project™ build system can be used package and manage deployment. This may mean integration into the image build or using a package stream or container store to enabled over the air updates to the running system further utilizing the EDF Linux Disk Images or user compiled disk image.

Typically this involves creating Yocto Project recipes for the applications within a meta layer, and then appending these recipes to the build target.

For Firmware (PL bitstream) bundles there are some inherited recipes that help convert the bitstream files (PDI) and Device Trees into the correct format to be used at runtime, in addition to adding them to the root FS build.

Next steps

Try it out on your evaluation board - Evaluation board based walkthrough tutorials all phases

Application Deployment using Yocto Recipes

Software Application Deployment - Software Applications

Kernel module Deployment - Kernel Drivers / Modules

Firmware Bundle Deployment - PL PDI and Device Tree

Container Image Hello World Example - Deploying using a container

 

OS integration & Development

The operating system (OS) developer creates custom OS images based on application or system requirements. In the simplest case, it is a plain Linux image, in more complex scenarios this can involve hypervisors, containers, multiple OSes based on processing domains e.g. RTOSes and bare-metal components etc. It also entails more low-level boot component like PMU, PLM and PSM firmware (AMD-specific), u-boot, ARM TF-A, OPTEE etc.

 

EDF uses the Yocto Project for its build system, it provides a build environment that allows users to create custom, complex, heterogenous boot and OS images.

Note: At this stage basic to advanced Yocto Project knowledge is required depending on the task you want to perform.

Next steps

Try it out on your evaluation board - Evaluation board based walkthrough tutorials all phases

https://xilinx-wiki.atlassian.net/wiki/x/3YAywg

Yocto Project™ build setup instructions

EDF Linux® disk image build using a prebuilt Yocto Project machines

Building Images with QEMU

Building an SDK for application cross development

https://xilinx-wiki.atlassian.net/wiki/x/AgDMwg

EDF Yocto Project™ build setup instructions

EDF Linux® disk image build using a prebuilt Yocto Project machines

Building Images for QEMU

Building an SDK for application cross development

 

Yocto Project - Basics, Common tasks, tips and tricks

Yocto Project components

  • BitBake: Core build tool and task scheduler, more flexible than traditional tools.

  • Metadata: Defines how software is built, configured, and packaged—organized in layers.

  • Poky: Yocto Project’s reference distribution, combining BitBake, OE-Core, and metadata to build custom Linux systems.

  • Yocto Project: Broader project providing tools and standards for building custom Linux distros

  • Layers: Modular metadata organization

  • Configuration files: define build settings, layer structure, machine specifics, and distribution policies to control how the system is built.

  • Recipes: metadata files (.bb) that define how to fetch, configure, build, and package software.

File naming and special characters in Yocto

Yocto has specific use for some characters such as underscore

  • Yocto does not support the use of underscores in recipe names (.bb)

    • “-” dash are allowed

    • “_” underscore are reserved and used as a delimiter to separate package names and version strings. For example : my-package_34.bb

Setting Up the Yocto Environment:

Configure git

$ git config --global user.email "you@example.com"

Using Repo to fetch and manage source layers

EDF uses the repo tool is used to manage multiple Git repositories that are needed by the Yocto build. Once installed ensure the tool is in the system path and that Git is properly configured.

You can then use repo to initialize and sync with the AMD yocto-manifests for EDF which define all required layers for a specific release. This will download all source repositories needed for the build.

Example:

#Download the Repo script: $ curl https://storage.googleapis.com/git-repo-downloads/repo > repo #Make it executable: $ chmod a+x repo #Move it on to the system path: $ mv repo ~/bin/ #repo init to the project of desire $ repo init -u <path to yocto-manifests for AMD EDF> -b <release-branch or release-tag> #repo sync to get all sources $ repo sync #optional $ repo start <branch_name> --all

Setting Up the Yocto Environment:

Use the scripts provided by AMD to configure the Yocto build environment. This is a wrapper around Yocto's oe-init-build-env and sets up paths, environment variables, and the build directory. Refer to the AMD Xilinx Yocto wiki for version details, features, and known issues: Yocto - Xilinx Wiki - Confluence

#source the environment to build using bitbake $ source <AMD EDF-init-build>-env

Configure your environment

Setup local downloads / sstate directories -  Save compile time (see below) https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586081/Development+Flows+-+How+it+all+works#Optimizing-Build-Time-in-Yocto

Download and install any lounge hosted items

For example, Meta-xlinx-restricted for EA Boards

$ bitbake-layers add-layer <path-to>/yocto/edf/sources/meta-xilinx-restricted-vek385

 

Generating the Yocto Machine (from the SDTgen output directory created from the Vivado xsa):

gen-machineconf tool converts hardware description data from the System Device Tree generator (SDTGen) output directory (part of the SHEL flow) into a Yocto-style machine configuration. It supports updates if the hardware description changes and should be used without manually modifying its output layers. This flow is used to create a Yocto Machine for any Vivado Project via the Shel flow

#Use gen-machineconf to create a machine using a downloaded pre-built 'System Device-tree Directory' $ gen-machineconf parse-sdt --hw-description <System Device-tree Directory> -c conf -l conf/local.conf --machine-name <Name for your machine/board>

Configuring the Yocto build: The target machine for the software build is set in the environment (build shell) or by editing local.conf. This tells Yocto which hardware platform the build is for.

# Set the machine in conf/local.conf sed -i "/MACHINE ??=/c\MACHINE ??= \"<Machine_Name>\"" conf/local.conf

Building the embedded software Image: Once the environment and machine configuration are in place, standard Yocto workflows are used to build images. Output images can be written to boot media to boot the board. Refer to AMD documentation for steps on booting and regenerating hardware designs.

bitbake <Image_Variant_Name>

Building from Remote Source Repository

Edit the BitBake recipe via vim sources/meta-user/recipes-apps/ssw_components/ssw_component.bbappend and input the following settings for building from a remote GitHub repository:

REPO = "https://github.com/Xilinx/embeddedsw " BRANCH = "master" SRCREV = "33750739285bbc8e51355b91cd274a1651e97e8f"

Building from Local External Repository

To build components from your local file system, add the following settings to the BitBake recipe:

# Build components from external src. INHERIT += "externalsrc" EXT_SRC_ESW = "<local repopath>" EXTERNALSRC:pn-plm-firmware = "${EXT_SRC_ESW}" EXTERNALSRC_BUILD:pn-plm-firmware = "${EXT_SRC_ESW}/build/plm" SRCREV:pn-plm-firmware = "84be8c5dce9325e9f7bb4279682c18846ecfd3b3"

Skipping Packaging Boot Components into Boot.Bin

To skip the packaging of boot components in the boot.bin file, add the following lines in the local.conf file:

BIF_PARTITION_ATTR:remove = "plmfw" BIF_PARTITION_ATTR:remove = "psmfw" BIF_PARTITION_ATTR:remove = "fsbl" BIF_PARTITION_ATTR:remove = "pmufw"

Optimizing Build Time in Yocto

Yocto supports smart caching through the use of shared download and sstate (shared state) directories. This significantly reduces build times, especially when reusing previously built artifacts with the same configuration.

To take advantage of this, users can configure their builds to pull prebuilt sources and build artifacts from centralized mirrors:

  • Source Mirrors: These allow fetching source files from a pre-populated mirror instead of downloading them individually from the internet.

  • Sstate Mirrors: These provide cached build results for previously built components, skipping the need to rebuild them locally.

By pointing to AMD's hosted mirrors (configured in local.conf), the build system can reuse existing outputs, dramatically speeding up the build process.

Optimizing build time locally - central download and SSTATE locations

You can also use a central downloads and SSTATE location outside of the project directory. Add the following line to your local.conf file to specify a central downloads or SSTATE directory. These locations could be used by multiple users

DL_DIR ?= "your_path" SSTATE_DIR ?= "your path"

For example:

DL_DIR ?= "/opt/yoctoCentralDownloads" SSTATE_DIR ?= "/opt/yoctoCentralSstate-cache"

This will allow the build system to access a centralized location for all downloads

Pre-defined Yocto Machines and Common recipes

See https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586143/Common+Specifications#EDF-prebuilt-Yocto-machine-definitions

Editing the RootFS configuration

There are multiple flows / options - See Yocto Project Documentation for full details

  4 Customizing Images — The Yocto Project ® 5.2.999 documentation

Some options -

Extending  the existing rootfs / image recipes :

meta-amd-edf/recipes-extended/<edf-linux-disk-image / edf-image-full-cmdline>

 

Add additional packages via the conf/local.conf:

IMAGE_INSTALL:append = “ openssh“    # Append a package using delayed append (to avoid un-intentional effects)

 

Use a .bbappend file (created in your own layer, added to the build)

$ mkdir meta-foo && mkdir recipes-foo $ cd recipes-foo $ vi edf-linux-disk-image.bbappend   IMAGE_INSTALL_append = “ openssh“ $ vi conf/local.conf BBLAYERS = “ \ ... <path>/meta-foo \ “ vi conf/bblayers.conf

 

Create your own custom image recipe (and include or run as a build target)

  • Create a new recipe (.bb) that inherits an existing recipe, and includes additional packages

require recipes-core/images/your-selected-image.bb

  • Target the new recipe at build time

Worked example - To edit the packages that are installed into the EDF rootFS follow the steps below. Also see the common specification pages to locate the source configuration for the EDF builds. https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586143/Common+Specifications#Linux-RootFS

 

  1. Select a predefined image recipe: Start by choosing an existing Yocto image recipe that matches your desired image variant, such as the EDF image that is the meta-amd-edf/recipes-extended/ folder. Examples edf-linux-disk-image edf-image-full-cmdline which both inherit and extend edf-image-common.inc (which contains a list of packages). Then, create a custom image recipe in your layer that requires the selected image recipe:

require recipes-core/images/your-selected-image.bb

  1. Customize the packages based on machine features: Tailor your custom image recipe to conditionally add, remove or modify packages based on the target machine's features. Use the MACHINE_FEATURES and bb.utils.contains function to check for specific features and adjust package lists accordingly:

IMAGE_INSTALL:append = "${@bb.utils.contains('MACHINE_FEATURES', 'feature-name', ' package-to-add', '', d)}" IMAGE_INSTALL:remove = "${@bb.utils.contains('MACHINE_FEATURES', 'feature-name', ' package-to-remove', '', d)}"

  1. Add custom configurations: In your image recipe or conf/local.conf, define your custom settings such as user management, package configurations (using PACKAGECONFIGs), custom files, file permissions, etc.

  2. Package groups and layers: You can create package groups to manage sets of related packages and use custom or third-party Yocto layers to incorporate additional software and components matching the desired image type.

  3. Rootfs size and post-processing: Depending on the image variant and machine features, you might want to adjust the rootfs size or perform post-processing tasks. Use the IMAGE_ROOTFS_* variables and ROOTFS_POSTPROCESS_COMMAND to manage rootfs configurations.

 

Customizing the Kernel in Your Yocto Build

There are multiple flows / options – See Yocto Project documentation for full details

https://docs.yoctoproject.org/5.0.9/kernel-dev/common.html#changing-the-configuration

https://docs.yoctoproject.org/5.0.9/kernel-dev/common.html#creating-configuration-fragments

Some options -

  • Specify a complete new .config file to be used in the build

  • Copy the .config to the recipe (${PN}) directory in your layer’s recipes-kernel/linux directory, rename to “defconfig”

  • Create a linux-yocto.bbappend  in your layer

FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:" SRC_URI += "file://defconfig"

  • Append config fragments to the build – Extending the existing .config

    • Create a config fragment (.cfg) using menuconfig and diffconfig (or manually)

    • Create a linux-yocto.bbappend  in your layer to pull in the fragment

FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:" SRC_URI += "file://<myFragName>.cfg“

 

Creating a image for multi-stage boot (Primary Boot Device → Secondary Boot device)

The EDF default boot architecture uses a 2-stage boot

Boot Architecture https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586143/Common+Specifications#Boot-Architecture-for-AMD-Evaluation-boards

Evaluation boards and default boot modes https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250585601/AMD+Embedded+Development+Framework+EDF#Packaged-BSP-for-AMD-Evaluation-Boards

  • Boot firmware loads from the Primary flash device, selecting the design to load ( boot.bin), which is hosted on the same flash

The boot firmware is included to provide image selection, secure A/B update, and recovery functionality. The Primary Boot device could only contain a boot.bin if this functionary was not required in your custom design or during development.

  • Operating Systems are then loaded from the secondary flash device that also hosts root file systems

 

The build flow is also in 2 sections - Primary Boot device, Secondary Boot device

Steps to build the images

See https://xilinx-wiki.atlassian.net/wiki/x/gADAwQ for full walkthrough examples for Evaluation boards

  1. Setup Yocto pre-requisites, see https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586081/Development+Flows+-+How+it+all+works#Setting-Up-the-Yocto-Environment%3A or follow https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3258089693/Operating+System+Integration+and+Development+AMD+Versal+device+portfolio#Yocto-Project-build-setup-instructions-for-EDF

#source the environment to build using bitbake $ source <AMD EDF-init-build>-env

 

  1. Build the boot.bin and EDF Boot firmware if applicable.

See https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586143/Common+Specifications#EDF-prebuilt-Yocto-machine-definitions for the list of prebuilt machines that support generating a boot.bin file for evaluation boards

For custom designs / boards the MACHINE may be the custom MACHINE created by gen-machine-conf

$ MACHINE=versal-2ve-2vm-vek385-sdt-seg bitbake edf-ospi

 

  1. Build the EDF Common disk images containing EDF Linux® OS using the correct MACHINE for your device family (Versal, MPSOC etc).

See https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586143/Common+Specifications#EDF-Common-disk-images-containing-EDF-Linux%C2%AE-OS----Yocto-machine-definitions-and-supported-recipes for pre-defined Yocto Machines applicable to AMD SoC devices

An example is shown below for amd-cortexa78-mali-common (Versal AI Edge Series Gen 2 )

linux-image-recipe

# Syntax: $ MACHINE=<machine-name> bitbake edf-linux-disk-image # Example Usage for versal ai edge series gen 2 $ MACHINE=amd-cortexa78-mali-common bitbake edf-linux-disk-image

 

3. Check the output – Deploy directory

$ ls -la tmp/deploy/images/versal-2ve-2vm-vek385-sdt-seg/ $ ls -la tmp/deploy/images/amd-cortexa78-mali-common/

4.Write to the flashes

  • OSPI / OSPI (boot firmware and boot.pdi)  – System Controller, fwupdate tool, Vivado

  • SDCARD / UFS (Common Linux image) – BMAP / Balena Etcher / dd / (System Controller for UFS)

5.Boot your board

Creating a bootable SD CARD image (Single stage boot : SD / eMMC / USB / UFS) - Combining boot.bin and EDF Linux® common disk image

To boot from SD card, or other single stage boot sources (eMMC / UFS / USB ), the board specific boot.bin (boot.pdi, tf-a, u-boot) needs to be added to the EDF Linux common disk image.

Boot Architecture https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586143/Common+Specifications#Boot-Architecture-for-AMD-Evaluation-boards

Evaluation boards and default boot modes https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250585601/AMD+Embedded+Development+Framework+EDF#Packaged-BSP-for-AMD-Evaluation-Boards

See https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586143/Common+Specifications#Files-required-for-booting-a-system for details of what files go into an image.

 

  1. Setup Yocto pre-requisites, see https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586081/Development+Flows+-+How+it+all+works#Setting-Up-the-Yocto-Environment%3A or follow https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3258089693/Operating+System+Integration+and+Development+AMD+Versal+device+portfolio#Yocto-Project-build-setup-instructions-for-EDF

 

  1. The boot.bin may have been built using a pre-defined Yocto Machines and provided recipes, using either prebuilt PDI artifacts (for an evaluation board), or from a compile of your custom design.

See https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3250586143/Common+Specifications#EDF-prebuilt-Yocto-machine-definitions for the list of prebuilt machines that support generating a boot.bin file.

xilinx-bootbin-recipe

# Syntax: $ MACHINE=<machine-name> bitbake xilinx-bootbin   # Example Usage for VEK280: $ MACHINE=versal-vek280-sdt-seg bitbake xilinx-bootbin # Example Usage for VCK190: $ MACHINE=versal-vck190-sdt-seg bitbake xilinx-bootbin

 

  1. The EDF Common disk images containing EDF Linux OS is built using the correct MACHINE for your device family (Versal, MPSOC etc)

An example is shown below for amd-cortexa72-common (Versal family)

Note: Versal-Net family is not supported in 2025.1.

linux-image-recipe

# Syntax: $ MACHINE=<machine-name> bitbake edf-linux-disk-image # Example Usage for versal-gp $ MACHINE=amd-cortexa72-common bitbake edf-linux-disk-image

 

  1. Add the boot.bin (created with xilinx-bootbin) to the EDF Common disk images to make single SD card image (boot.bin, kernel, rootfs, boot script), by adding the boot.bin to the EFI partition in the WIC Image (Partition 0 = index 1 in the WIC)

The below flows use the WIC, and WIC tools are available from within the Yocto build environment, but you may need to install additional packages (not included in the Yocto setup)

  • wic uses mcopy which is provided by the mtools package on Canonical Ubuntu - sudo apt install mtools

Other flows and tools can be used to update the .tar.gz archive version.

 

# help for wic $ wic help # list the partition map of the .wic file $ wic ls <path to wic>/edf-linux-disk-image-amd-cortexa72-common.rootfs.wic Num Start End Size Fstype 1 4096 536875007 536870912 fat32 2 536875008 1073745919 536870912 ext4 3 1073745920 8589938687 7516192768 ext4 4 8589938688 9663680511 1073741824 fat32 # show the content of the efi partition (intex 1) (empty) $ wic ls <path to wic>/edf-linux-disk-image-amd-cortexa72-common.rootfs.wic:1 Volume in drive : is efi Volume Serial Number is 277A-85A9 Directory for ::/ No files 535 797 760 bytes free # Copy the boot.bin into the efi partition of the wic image $ wic cp tmp/deploy/images/versal-vek280-sdt-seg/boot.bin tmp/deploy/images/amd-cortexa72-common/edf-linux-disk-image-amd-cortexa72-common.rootfs.wic:1 # Check the content of the wic $ wic ls <path to wic>/edf-linux-disk-image-amd-cortexa72-common.rootfs.wic:1 Volume in drive : is efi Volume Serial Number is 277A-85A9 Directory for ::/ boot bin 3018224 2025-07-23 10:18 1 file 3 018 224 bytes 532 779 008 bytes free

  1. The .wic image (or other updated image) can the be flashed to the SD card

 

Custom Hardware Development

This section shows how to generate a base HW design and its firmware package and two examples of application-specific HW designs and firmware, one is a Vivado Design Suite based design (RTL), the other a Vitis™ software platform-based design. We show how to generate various handoff artifacts needed when moving from HW to the SW or OS domain, and the flow to build the complete runtime image.

Next steps

Try it out on your evaluation board - Evaluation board-based walk-through tutorials all phases

https://xilinx-wiki.atlassian.net/wiki/x/nAE0wg

EDF Hardware Design Repository Overview

Vivado base design and base platform

Generating a new Yocto Project Machine Configuration based on the Vivado Design Suite Project (xsa)

 

https://xilinx-wiki.atlassian.net/wiki/x/AQDNwg

EDF Hardware Design Repository Overview

Vivado base design and base platform

Generating a new Yocto Project Machine Configuration based on the Vivado Design...

Migrating a project from PetaLinux to EDF / Yocto Project (Creating a Yocto based embedded software image from a Vivado .xsa

  • This documentation will be extended shortly after release (1-2 weeks)

Introduction

If user has existing XSCT flow or SHELL flow based Petalinux project with his custom configurations, he can migrate to EDF flow by following the below guide.

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

 

 

 

Additional references

Isolation and protection

AMD EDF 25.05 (VEK385 EA) - AMD Vivado Design Suite 2025.1

  • Support for Isolation and Protection in EDF BSPs (delivered) via the SHEL flows is currently scheduled for the next release of EDF.

Related Links

  •  

Child Pages


Trademarks

Yocto Project and all related marks and logos are trademarks of The Linux Foundation. This website is not, in any way, endorsed by the Yocto Project or The Linux Foundation.

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.



 

© 2025 Advanced Micro Devices, Inc. Privacy Policy