.. # SPDX-FileCopyrightText: Copyright 2025 Arm Limited and/or its # affiliates # # SPDX-License-Identifier: MIT .. _rd-aspen_design_systemready_devicetree: ########################## Arm SystemReady Devicetree ########################## :link_subs:`common:arm-systemready` is a compliance certification program based on a set of hardware and firmware standards that enable interoperability with generic off-the-shelf operating systems and hypervisors. These standards include the :link_subs:`common:base-system-architecture` and :link_subs:`common:base-boot-requirements` specifications, and market-specific supplements. In this way, the :link_subs:`common:arm-systemready-program` provides a formal set of compute platform definitions to cover a range of systems from the cloud to IoT and edge, helping software 'just work' seamlessly across an ecosystem of Arm-based hardware. Arm SystemReady is divided into two bands, each with a combination of specs available to suit the different devices and markets. Arm SystemReady Devicetree is one of these bands. :link_subs:`rd-aspen:arm-systemready-devicetree` certified platforms implement a minimum set of hardware and firmware features that an operating system can depend on to deploy the operating system image. Hence, Arm SystemReady Devicetree ensures that the deployment and maintenance of standard firmware interfaces and targets both custom (Yocto, OpenWRT, Buildroot) and pre-built (Debian, Fedora, SUSE) Linux distributions. At a high level, the Devicetree band requires that: * Hardware implements the Base System Architecture (BSA) * Firmware implements a subset of UEFI as defined in Embedded Base Boot Requirements (EBBR) * Firmware by default provides a device tree suitable for booting mainline Linux * Firmware can be updated using UEFI ``UpdateCapsule()`` * At least three Linux distros must be able to boot, install, and run storage medium tests using the UEFI boot flow Compliant systems must conform to the: * :link_subs:`common:base-system-architecture` specification * :link_subs:`common:embedded-base-boot-requirements` * EBBR recipe of the Arm :link_subs:`common:base-boot-requirements` specification * :link_subs:`common:devicetree-specification` * Ethernet port requirements It is also recommended to conform to the :link_subs:`common:base-boot-security-requirements` specification. If that's not possible, the following rules are still required: * R140_BBSR: Capsule payloads for updating system firmware must be digitally signed * R150_BBSR: Before updates to system firmware are applied, images must be verified using digital signatures *********************************** Support in Arm Automotive Solutions *********************************** This Reference Software Stack aims to be aligned with Arm SystemReady Devicetree version |SystemReady Devicetree ACS version| by implementing most of its requirements. Given this is a reference design, the software is not being submitted for formal certification. The support for running the Architectural Compliance Tests (ACS) is included in the Reference Software Stack. For more details on how to run it, see the :ref:`rd-aspen_user_guide_reproduce_sr_devicetree_acs` section of this documentation. The results are compared with an expected platform baseline, which contains identified non-alignments described in the :ref:`rd-aspen_boot_process_systemready-non_alignments` section below. .. _rd-aspen_boot_process_systemready-non_alignments: ************************************* Identified non-alignments on RD-Aspen ************************************* The Reference Software Stack is currently known to have the following non-alignments: * Reference Software Stack * RD-Aspen does not support populating the list of runtime variables, which will lead to "Can't populate EFI variables. No runtime variables will be available". * RD-Aspen does not support Capsule Updates. * RD-Aspen does not support verifying signed db/dbx update, which will lead to "SecureBoot - Verify signed db/dbx update" test failures in BBSR. * RD-Aspen does not support querying authenticated variables, which will lead to "RT.QueryVariableInfo - Query Auth Variable" test failures in BBSR. * RD-Aspen does not support time base authenticated variables, which will lead to a "RT.SetVariable" test failure in BBSR. * Devicetree * Missing schemas for components which have not yet been or are not appropriate to be upstreamed (``arm,rdaspen``, ``arm,cortex-a720ae``, ``arm,dsu-l3-cache``, ``arm,si-rproc``). * U-Boot * Known limitations of EFI implementation which are excluded in the :link_subs:`common:ebbr-specification-uefi-runtime-services`. * Known limitations of EFI implementation which are noted as 'Explicit justification in a future revision of EBBR is pending' by :link_subs:`rd-aspen:edk2-test-parser`. * Model - FVP * Platform-specific limitations, which are noted as excluded in the :link_subs:`common:ebbr-specification-required-platform-specific-elements`. * ``AES``, ``SHA1`` and ``SHA2`` instructions are marked as unavailable in the FVP ``ID_AA64ISAR0_EL1``. * Test environment * No text input is available in the test environment for Simple Text Input Ex protocol. * BSA tests * Tests are not compatible with certain devices in the RD-Aspen model. ******************************** Arm SystemReady Devicetree tests ******************************** .. _rd-aspen_systemready_devicetree_acs_tests: Arm SystemReady Devicetree ACS tests ==================================== The Arm SystemReady Architecture Compliance Suite (ACS) is a set of tests that ensure architectural compliance across different implementations and variants of the architecture. The ACS is delivered as a prebuilt release image. The image is a bootable live OS image containing a collection of test suites. The ACS includes an optional :link_subs:`base-boot-security-requirements` test. This Reference Software Stack supports running the BBSR suite to test authenticated variables, UEFI Secure Boot variables, and UEFI Secure Boot image loading. The :repo:`yocto/meta-arm-systemready-devicetree/classes/arm-systemready-acs.bbclass` class contains the common logic to deploy the Arm SystemReady Devicetree ACS version |SystemReady Devicetree ACS version| pre-built image and set up the testimage environment. It also contains a testimage "postfunc" called ``acs_logs_handle`` which generates report files and checks the results. The script :repo:`yocto/meta-arm-systemready-devicetree/lib/oeqa/runtime/cases/arm_systemready_devicetree_acs.py` monitors the ACS tests output from the bitbake testimage task. To run the tests, see :ref:`rd-aspen_user_guide_reproduce_sr_devicetree_acs`. .. _systemready_devicetree_linux_install: Linux Distributions Installation Tests ====================================== The Arm SystemReady Devicetree requires that at least three Linux distributions must be able to boot and install using the UEFI boot flow. Recipes for testing the installation of Linux distributions are provided under :meta-arm-repo:`meta-arm-systemready/recipes-test/arm-systemready-linux-distros`. These recipes help to download the installation CD for the Linux distribution and generate an empty disk as the target disk for the installation. See :meta-arm-repo:`meta-arm-systemready/README.md` for more details. To run the tests, see :ref:`user_guide_reproduce_arm_systemready_devicetree_linux`.