Introduction
Overview
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.
Audience
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.
This document describes how to build an image for Armv8-R AArch64 using a Yocto Project 5 build environment. Basic instructions can be found in the Yocto Project Quick Start 6 document.
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
Virtualization solution
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
Instructions for achieving these use cases are given in the article Reproduce, subject to the relevant assumed technical knowledge as listed at the Audience section in this document.
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.
Features Overview
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
Documentation Overview
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.
Repository Structure
The Armv8-R AArch64 software stack is provided through the v8r64 repository 13, which is structured as follows:
meta-armv8r64-extrasYocto 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.
documentationDirectory which contains the documentation sources, defined in reStructuredText (.rst) format for rendering via Sphinx 17.
configDirectory 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.
Repository License
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.
Issue Reporting
To report issues with the repository such as potential bugs, security concerns, or feature requests, please submit an Issue 18 via GitLab 13, following the project’s Issue template.
Feedback and Support
To request support please contact Arm at support@arm.com. Arm licensees may also contact with Arm via their partner managers.
Maintainer(s)
Diego Sueiro <diego.sueiro@arm.com>
Robbie Cao <robbie.cao@arm.com>
Reference
- 1
- 2
- 3
- 4
- 5
- 6
https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html
- 7
- 8
https://git.kernel.org/pub/scm/linux/kernel/git/mark/boot-wrapper-aarch64.git/
- 9
- 10
- 11
- 12
- 13(1,2)
- 14
https://git.yoctoproject.org/meta-arm/tree/meta-arm-bsp/documentation/fvp-baser-aemv8r64.md
- 15
https://git.yoctoproject.org/meta-arm/tree/meta-arm-bsp?h=kirkstone
- 16
- 17
- 18
https://gitlab.arm.com/automotive-and-industrial/v8r64/-/issues