Getting Started - Walkthrough Examples
This page is a getting-started guide, providing walkthrough style examples using the AMD Embedded Development Framework (EDF). It covers initial board setup and running a prebuilt disk image, hardware, and software applications development using the prebuilt image, and full custom hardware and software builds and image creation.
Table of Contents
Introduction
The following sections walk a user through the AMD EDF, moving through the development personas shown in the picture below, from initial board setup and exploration using a prebuilt image, to on-target development, deployment options, and custom flows.
Not all flows are applicable to all evaluation boards -
For example, some evaluation board BSP have different boot architecture
VEK385: Multistage boot
“How to boot a board using the prebuilt images: Single-stage boot SD mode - Setup” is not applicable.
VEK280: Single-stage boot
How to boot a board using the prebuilt images: Multistage boot (QSPI / OSPI -> SD/UFS) - Setup is not applicable
See AMD Embedded Development Framework (EDF) | Packaged BSP for AMD evaluation boards and https://xilinx-wiki.atlassian.net/wiki/x/rALAwQ
Discovery and Evaluation
The first step of the journey is switching on the board and seeing it work. Exploration can then begin using the provided reference designs. This section walks a user through the Discovery and Evaluation persona within the AMD EDF, which covers initial board setup and exploration using a prebuilt image.
Discovery and Evaluation AMD Versal Device Portfolio
Discovery and Evaluation AMD Versal Device Portfolio | System Controller Enabled Evaluation Boards System Controller Firmware Update - Updating the onboard System Controller
Discovery and Evaluation AMD Versal Device Portfolio | Image Recovery Application - How to use the built-in image recovery and selection support
Discovery and Evaluation AMD ZynqMP™ device portfolio
Applications targeting adaptive SoCs typically consist of hardware and software components. Hardware components include PL and/or AI Engine payloads typically provided as PDI and/or xclbin; software components include device drivers (for example, Linux® kernel modules) and software libraries / applications (Linux user-space).
In Linux, hardware payloads are packaged as firmware binaries (for example, PDI with device tree binary overlay (DTBO)). Different aspects of application development can be performed on target, or on a host PC using a cross-development SDK environment. This allows the user to quickly test, debug, and iterate over changes.
When the application is stable and ready for release, the Yocto™ Project build system provides a way to package applications for production deployment.
On-target development is convenient because you can use native compilers and tools, and a workflow most developers are used to, similar to doing native x86 development on a workstation. You can install a rich set of dev packages from the package feed and use familiar build systems such as make, autotools, cmake, or meson without having to set up a cross-development environment.
An SDK for cross-development on an x86 host is useful when a user does not have access to a board for on-target development. Depending on the project, it 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.
This section covers how to generate PL images compatible with a base design or the EDF prebuilt images, using Segmented Configuration. This enables a different payload (PL or other) to be loaded or re-loaded from Linux at runtime, speeding up development (by testing on running system) and enabling dynamic payload management on deployed systems with Linux / U-Boot as the system manager (for example, version management, fallback, or recovery).
When applications have been created, the Yocto build system can be used to package and manage deployment. This might mean integration into the image build or using a package stream or container store to enable over-the-air updates to the running system.
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3258090263/Application+Deployment+using+Yocto+Recipes+AMD+Versal+device+portfolio#Software-Application-Deployment - Software Applications
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3258090263/Application+Deployment+using+Yocto+Recipes+AMD+Versal+device+portfolio#Kernel-module - Kernel Drivers / Modules
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3258090263/Application+Deployment+using+Yocto+Recipes+AMD+Versal+device+portfolio#Firmware-Bundle - PL PDI and Device Tree
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/3258090263/Application+Deployment+using+Yocto+Recipes+AMD+Versal+device+portfolio#Deploying-a-Container-Image---Hello-World-Example - Deploying using a container
OS Integration and 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, or multiple OSes based on processing domains (e.g., RTOSes, bare-metal components, etc).
It also entails more low-level boot components such as PMU, PLM, and PSM firmware (AMD-specific), U-Boot, ARM TF-A, OPTEE, etc. The Yocto Project provides a build environment that allows users to create custom, complex, heterogeneous boot, and OS images.
Note: At this stage, basic to advanced Yocto knowledge is required depending on the task you want to perform.
https://xilinx-wiki.atlassian.net/wiki/x/3YAywg
https://xilinx-wiki.atlassian.net/wiki/x/AgDMwg
Custom Hardware Development
This section shows how to generate a base hardware design and its firmware package and two examples of application-specific hardware designs and firmware.
One is an AMD Vivado™ Design Suite based design (RTL); the other is an AMD Vitis™ software platform-based design. We show how to generate various handoff artifacts, needed when moving from Hardware to the Software or OS domain, and the flow to build the complete runtime image.
https://xilinx-wiki.atlassian.net/wiki/x/nAE0wg
https://xilinx-wiki.atlassian.net/wiki/x/AQDNwg
Custom Hardware Development AMD ZynqMP™ device portfolio | EDF Hardware Design Repository Overview Custom Hardware Development AMD ZynqMP™ device portfolio | Vivado base design and base platform
Child pages
- Discovery and Evaluation AMD Versal Device Portfolio
- Discovery and Evaluation AMD ZynqMP™ device portfolio
- Application Development and Deployment
- Operating System Integration and Development AMD Versal™ device portfolio
- Custom Hardware Development AMD Versal™ device portfolio
- Operating System Integration and Development AMD ZynqMP™ device portfolio
- Custom Hardware Development AMD ZynqMP™ device portfolio
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