The Armv8-R AArch64 software stack is a collection of example software compositions for the Armv8-R AEM FVP model 1, an implementation of the Armv8-R AArch64 architecture 2. The Open Source example software coupled with the Armv8-R AEM FVP enable the exploration of the general Armv8-R AArch64 architecture as well as its specific implementation - Cortex-R82 3, where FVP stands for Fixed Virtual Platforms, and AEM stands for Architecture Envelope Model.
This software stack supports two types of operating system: Linux as the Rich OS and Zephyr as the RTOS (Real-Time Operating System), and can run either on baremetal (without hardware virtualization) or virtualization with Xen as Type-1 hypervisor. It is provided via a set of Yocto layers which contains all the instructions necessary to fetch and build the source as well as to download the model and launch the example.
Fixed Virtual Platforms (FVP) are complete simulations of an Arm system, including processor, memory and peripherals. These are set out in a “programmer’s view”, which gives you a comprehensive model on which to build and test your software. The Fast Models FVP Reference Guide 4 provides the necessary details. The Armv8-R AEM FVP is a free of charge Armv8-R Fixed Virtual Platform. It supports the latest Armv8-R feature set.
This document describes how to build and run the Armv8-R AArch64 software stack on the Armv8-R AEM FVP (AArch64) platform. It also covers how to extend features and configurations based on the software stack.
This document is intended for software, hardware, and system engineers who are planning to use the Armv8-R AArch64 software stack, and for anyone who wants to know more about it.
In addition to having Yocto related knowledge, the target audience also need to have a certain understanding of the following components:
Use Cases Overview
There are 3 configurations supported in the software stack for either baremetal solution or virtualization solution separately:
Baremetal solution (without hardware virtualization support)
Boot a Linux based Rich OS (via U-boot with UEFI) to command prompt
Boot Zephyr RTOS directly and run a sample application
Boot the Xen hypervisor (via U-boot without UEFI) and start two isolated domains to run Linux Rich OS and Zephyr RTOS in parallel on the fixed number of cores assigned statically by the Xen hypervisor
High Level Architecture
The high-level architecture corresponding to the three use cases (as described in the Use Cases Overview section above) supported by this software stack is as follows:
The diagram below gives an overview of the components and layers in the baremetal Zephyr implementation in this stack.
The diagram below gives an overview of the components and layers in the baremetal Linux implementation in this stack.
The diagram below gives an overview of the components and layers in the implementation of virtualization with Xen hypervisor in this stack.
This software stack implements the following major features at system level:
A Zephyr RTOS running on baremetal supporting SMP (Symmetric Multi-Processing)
A standard Linux Rich OS running on baremetal supporting the following functions:
Booting Linux kernel using U-Boot UEFI (Unified Extensible Firmware Interface) and Grub2
SMP (Symmetric Multi-Processing)
Test suite that can validate the basic functionalities
A dual-OS system - Zephyr as the RTOS and Linux as the Rich OS - running in parallel using the Xen hypervisor, with supporting the following functions:
Booting dom0less Xen from U-Boot
SMP in Xen hypervisor and the OSes (both Linux and Zephyr) running in Xen domains
Test suite that can validate the basic functionalities in Linux
Classic sample applications in Zephyr
Some other features at component level include:
Device tree overlay to apply changes on the fly (provided by U-Boot)
Device pass through support for virtio-net, virtio-blk, virtio-rng, virtio-9p and virtio-rtc (provided by Xen to the Linux kernel)
PSCI service (provided by boot-wrapper-aarch64)
Boot from S-EL2 (provided by boot-wrapper-aarch64, U-Boot and Xen)
Boot-wrapper-aarch64 (as an alternative solution to Trusted-Firmware) and hypervisor (Xen) co-existence in S-EL2 at runtime
The documentation is structured as follows:
Provides the guide to setup environment, build and run the software stack on the target platform, run the provided test suite and validate supported functionalities. Also includes the guidance for how to use extra features, customize configurations, and reuse the components in this software stack.
Provides more advanced developer-focused details about this software stack, include its implementation, and dependencies, etc.
Defines the license under which this software stack is provided.
Documents new features, bug fixes, known issues and limitations, and any other changes provided under each release.
The Armv8-R AArch64 software stack is provided through the v8r64 repository 13, which is structured as follows:
Yocto layer with the target platform (fvp-baser-aemv8r64 14) extensions for Armv8-R AArch64. This layer extends the meta-arm-bsp 15 layer in the meta-arm 16 repository. It aims to release the updated and new Yocto Project recipes and machine configurations for Armv8-R AArch64 that are not available in the existing meta-arm and meta-arm-bsp layers in the Yocto Project. This layer also provides image recipes that include all the components needed for a system image to boot, making it easier for the user. Components can be built individually or through an image recipe, which pulls all the components required in an image into one build process.
Directory which contains the documentation sources, defined in reStructuredText (.rst) format for rendering via Sphinx 17.
Directory which contains configuration files for running tools on the v8r64 repository, such as files for running automated quality-assurance checks.
The Yocto layers which are provided by meta-armv8r64-extras are detailed with the layer structure and dependencies in Yocto Layers.
The repository’s standard license is the MIT license (more details in License), under which most of the repository’s content is provided. Exceptions to this standard license relate to files that represent modifications to externally licensed works (for example, patch files). These files may therefore be included in the repository under alternative licenses in order to be compliant with the licensing requirements of the associated external works.
Contributions to the project should follow the same licensing arrangement.
Feedback and Support
To request support please contact Arm at email@example.com. Arm licensees may also contact with Arm via their partner managers.