The software platform serves as the foundation for running applications on AMD-powered Versal and ZynqMP devices. The software platform provides the environment to run and control kernels. It serves as the control mechanism for both fixed and extensible platforms. It includes the domain setup and boot components for setting up, resetting and configuring the hardware platform. The software platform encompasses several key elements:
- System Device Tree
- This file defines the components and configurations of your hardware, enabling proper interaction with the software.
- Board Support Package (BSP)
- This package houses libraries and drivers specific to your platform, providing access to functions like peripherals, memory management, and processor communication.
- Operating System and Boot Components
- These components manage loading and running the software on your platform. The Linux option offers extensive features, while bare-metal and RTOS provide more focused control and real-time performance.
Support for Operating System and Processors
The software platform supports various operating systems across different processors:
- Bare-Metal
- Ideal for resource-constrained applications, it runs on APU, RPU, and PMC processors and provides a basic single-threaded environment.
- Linux
- Designed for multi-user and multi-tasking environments, it operates on APU processors and leverages open-source drivers for all processing system peripherals.
- RTOS
- This option caters to applications requiring deterministic scheduling and low latency, typically found in APU, RPU, and PMC environments.
Bare-metal
AMD provides a bare-metal software stack included within the AMD Vitis tools package. This software includes a simple, single-threaded environment tailored for resource-constrained hardware. It provides support for standard input/output and access to essential processor hardware features. The bare-metal software includes board support packages (BSP) containing standalone drivers and libraries. These components are configurable to provide the necessary functionality with minimal overhead, ensuring efficient resource utilization. This software stack is specifically designed for RPU and APU processors commonly found in embedded systems. The XSCT command line tool can be used to configure and build the BSPs.<Vitis Installation Directory>\Vitis\<version>\data\embeddedsw\XilinxProcessorIPLib\drivers<Vitis Installation Directory>\Vitis\<version>\data\embeddedsw\lib\sw_servicesLinux Based
The Linux-based software platform is supported on the APU processors of both Versal and Zynq UltraScale+ MPSoC devices. The software platform components can also be generated using PetaLinux, Yocto, or other third-party frameworks. To control the AI Engine graphs and/or PL kernels from the software application running on Linux you must configure and enable the XRT drivers in the software platform.
This platform consists of:
- Root File System (RFS)
- This includes essential binaries, libraries, and configurations for a functional Linux file system.
- Kernel Image
- This refers to the compiled Linux kernel with supported peripheral drivers.
- Sysroot
- This tool allows for cross-compilation of the host application, providing the necessary libraries for compiling applications for the target system.
All pre-built AMD platforms have the software platform provided. By default, the platforms have a Linux domain with the Xilinx Runtime (XRT) enabled so that applications can run on the platform. Because the device tree is unique to each platform, it is provided as a component with the Linux XRT domain inside the platform. Common software images can be downloaded from the Embedded Platforms download page.
The source files for embedded platforms are available on GitHub at Vitis Embedded Platform
Source. You can use these files as a reference for your custom software platform development.
RTOS
The FreeRTOS BSP provides a lightweight, multi-threaded environment tailored for embedded systems. It offers basic functionalities like standard input, output, and access to processor hardware features. The BSP and its associated libraries are highly configurable, allowing developers to achieve necessary functionalities with minimal resource overhead.
The FreeRTOS software stack closely resembles the bare-metal stack, but it incorporates the FreeRTOS library, enabling real-time multitasking capabilities. Importantly, AMD device drivers included with the standalone libraries can be seamlessly integrated within FreeRTOS, provided that only a single thread requires access to the device.
For more insight into the FreeRTOS software stack, refer to the section: FreeRTOS Software Stack in the Versal Adaptive SoC System Software Developers Guide (UG1304).
Boot Components
The software platform components are compiled as binaries, and are packaged along with the hardware platform into device images. The AMD boot image format (BIF) file is used to stitch binary files together and generate device boot images. Bootgen defines multiple properties, attributes, and parameters that used in creating boot images for use in an AMD device.
The following is an example of a BIF file targeting a ZYNQMP device:
the_MCS_image:
{
[bootloader, destination_cpu=a53-0] <plnx-proj-root>/images/linux/
zynqmp_fsbl.elf
[pmufw_image] <plnx-proj-root>/images/linux/pmufw.elf
[destination_device=pl] <plnx-proj-root>/project-spec/hw-description/
project_1.bit
[destination_cpu=a53-0, exception_level=el-3, trustzone] <plnx-proj-root>/
images/linux/bl31.elf
[destination_cpu=a53-0, load=0x00100000] <plnx-proj-root>/images/linux/
system.dtb
[destination_cpu=a53-0, exception_level=el-2] <plnx-proj-root>/images/
linux/u-boot.elf
}The following is an example of a BIF file targeting a Versal device:
the_ROM_image:
{
{ type=bootimage, file=<system_project_path>/system.pdi }
}
image
{
name=aie_image, id=0x1c000000
{ type=cdo
/* The following commented lines show the CDOs used to create a merged CDO 'aie.cdo.merged.bin'. For debugging purpose,
uncomment these CDOs and comment the line that adds 'aie.cdo.merged.bin' */
/*
file = <aie_project_path>/package/libadf/sw/aie.cdo.reset.bin
file = <aie_project_path>//package/libadf/sw/aie.cdo.clock.gating.bin
file = <aie_project_path>//package/libadf/sw/aie.cdo.error.handling.bin
file = <aie_project_path>//package/libadf/sw/aie.cdo.elfs.bin
file = <aie_project_path>//package/libadf/sw/aie.cdo.init.bin
*/
<aie_project_path>/package.hw/aie.merged.cdo.bin
}
}
image
{
name=default_subsys, id=0x1c000000
{ load=0x1000, file=<project_path>/system.dtb }
{ core=a72-0, exception_level=el-3, trustzone, file=<project_path>/boot/bl31.elf }
{ load=0x8000000, core=a72-0, exception_level=el-2, file=<project_path>/boot/u-boot.elf }
}
The steps to integrate a hardware platform with the software platform and generate boot images that can be used on the board, based on the Vitis flow used, is described here: Integrating the System.