diff options
73 files changed, 451 insertions, 11287 deletions
diff --git a/docs/basefvp/user-guide.rst b/docs/basefvp/user-guide.rst index 52b49f7..62d751e 100644 --- a/docs/basefvp/user-guide.rst +++ b/docs/basefvp/user-guide.rst @@ -1,254 +1,2 @@ -User Guide -========== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Notice ------- - -The FVP-BASE software stack uses the `Yocto project <https://www.yoctoproject.org/>`__ -to build a Board Support Package (BSP) and the Poky Linux distribution. -The Yocto project uses `Bitbake <https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html>`__ -to build the software stack. - - -Prerequisites -------------- - -These instructions assume that: - * Your host PC is running Ubuntu Linux 18.04 LTS. - * You are running the provided scripts in a ``bash`` shell environment. - -The following utilities must be available on your host PC: - * chrpath - * compression library - * diffstat - * gawk - * makeinfo - * openssl headers - * pip - * repo - * yocto - -To resolve these dependencies, run: - -:: - - sudo apt-get update - sudo apt-get install chrpath gawk texinfo libssl-dev diffstat wget git-core unzip gcc-multilib \ - build-essential socat cpio python python3 python3-pip python3-pexpect xz-utils debianutils \ - iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm git-lfs openssl \ - curl libncurses-dev libz-dev python-pip repo - - -Obtaining Armv8-A Base Platform FVP ------------------------------------ - -Armv8-A Base Platform FVP can be downloaded from -`here <https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms>`_. - - -Follow the instruction in the installer and setup the FVP. - -Before launching any scripts from ``model-scripts`` folder, export the absolute -path of the model as an environment variable. - -:: - - export MODEL=<absolute-path-of-the-model-executable> - -This completes the steps to obtain Armv8-A Base Platform FVP. - -Syncing and building the source code ------------------------------------- - -Create a new folder that will be your workspace, which will henceforth be referred to as ``<workspace>`` -in these instructions. - -:: - - mkdir <workspace> - cd <workspace> - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m fvp-yocto.xml -b refs/tags/BASEFVP-2020.08.06 - repo sync -j${NUM_CPUS} - export DISTRO="poky" - export MACHINE="fvp-base" - source setup-environment - bitbake core-image-minimal - -The initial clean build will be lengthy, given that all host utilities are to be built as well as -the target images. This includes host executables (python, cmake, etc.) and the required toolchain(s). - -Once the build is successful, all images will be placed in the ``<workspace>/build-poky/tmp-poky/deploy/images/fvp-base`` -directory. - -Note that the BSP includes the Poky Linux distribution, which offers BusyBox-like utilities. - -Provided components -------------------- - -Within the Yocto project, each component included in the FVP-BASE software stack is specified as -a `Bitbake recipe <https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#recipes>`__. -The FVP-BASE recipes are located at ``<workspace>/layers/meta-arm/``. - - -Software Components -################### - -Trusted Firmware-A -****************** - -Based on `Trusted Firmware-A <https://trustedfirmware-a.readthedocs.io/en/latest/>`__ - -+--------+----------------------------------------------------------------------------------------------------+ -| Recipe | <workspace>/layers/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-fvp.inc | -+--------+----------------------------------------------------------------------------------------------------+ -| Files | * <workspace>/build-poky/tmp-poky/deploy/images/fvp-base/bl1-fvp.bin | -| | * <workspace>/build-poky/tmp-poky/deploy/images/fvp-base/fip-fvp.bin | -+--------+----------------------------------------------------------------------------------------------------+ - -U-Boot -****** - -Based on `U-Boot gitlab <https://gitlab.denx.de/u-boot/u-boot>`__ - -+--------+-------------------------------------------------------------------------------+ -| Recipe | <workspace>/layers/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_%.bbappend | -+--------+-------------------------------------------------------------------------------+ -| Files | * <workspace>/build-poky/tmp-poky/deploy/images/fvp-base/u-boot.bin | -+--------+-------------------------------------------------------------------------------+ - - -Linux -***** - -The recipe responsible for building a 5.4 version of the Yocto Linux kernel - -+--------+-----------------------------------------------------------------------------------+ -| Recipe | <workspace>/layers/openembedded-core/meta/recipes-kernel/linux/linux-yocto_5.4.bb | -+--------+-----------------------------------------------------------------------------------+ -| Files | * <workspace>/build-poky/tmp-poky/deploy/images/fvp-base/Image | -+--------+-----------------------------------------------------------------------------------+ - - -Poky Linux distro -***************** - -The layer is based on the `poky <https://www.yoctoproject.org/software-item/poky/>`__ Linux distribution. -The provided distribution is based on BusyBox and built using glibc. - -+--------+-----------------------------------------------------------------------------------------------+ -| Recipe | <workspace>/layers/openembedded-core/meta/recipes-core/images/core-image-minimal.bb | -+--------+-----------------------------------------------------------------------------------------------+ -| Files | * <workspace>/build-poky/tmp-poky/deploy/images/fvp-base/core-image-minimal-fvp-base.disk.img | -+--------+-----------------------------------------------------------------------------------------------+ - - -Running the software on FVP ---------------------------- - -The run-scripts structure is as follows: - -:: - - run-scripts - |--fvp - |--run_model.sh - |-- ... - -Ensure that all dependencies are met by executing the FVP: $MODEL`. You should see -the FVP launch, presenting a graphical interface showing information about the current state of the FVP. - -The ``run_model.sh`` script in ``<workspace>/run-scripts/fvp`` will launch the FVP. -Set environment variables and execute the ``run_model.sh`` as follows: - -:: - - export IMAGE=<workspace>/build-poky/tmp-poky/deploy/images/fvp-base/Image - export BL1=<workspace>/build-poky/tmp-poky/deploy/images/fvp-base/bl1-fvp.bin - export FIP=<workspace>/build-poky/tmp-poky/deploy/images/fvp-base/fip-fvp.bin - export DISK=<workspace>/build-poky/tmp-poky/deploy/images/fvp-base/core-image-minimal-fvp-base.disk.img - export DTB=<workspace>/build-poky/tmp-poky/deploy/images/fvp-base/fvp-base-gicv3-psci-custom.dtb - - cd <workspace>/run-scripts/fvp - ./run_model.sh - -Enable network on FVP ---------------------- - -To enable network on FVP, follow below steps - -1. Create network bridge and add the host PC network as its interface: -:: - - sudo apt-get install bridge-utils - sudo brctl addbr br0 - sudo brctl addif br0 <host network interface name> - sudo ifconfig <host network interface name> 0.0.0.0 - sudo ifconfig br0 up - sudo dhclient br0 - -2. Add the tap interface: -:: - - sudo ip tuntap add dev <bridge_interface_name> mode tap user $(whoami) - sudo ifconfig <bridge_interface_name> 0.0.0.0 promisc up - sudo brctl addif br0 <bridge_interface_name> - -3. Add below parameters in run_model.sh: -:: - - -C bp.hostbridge.interfaceName=<bridge_interface_name> - -C bp.smsc_91c111.enabled=1 - -4. ./run_model.sh - -Build and Run AArch32 builds on Armv8-A Base Platform FVP ---------------------------------------------------------- - -Build: Follow the steps explained above, however set the MACHINE variable as follows: - -:: - - export MACHINE="fvp-base-arm32" - -Note: Output files become available in the <workspace>/build-poky/tmp-poky/deploy/images/fvp-base-arm32 folder. -Set environment variables accordingly: - -:: - - export IMAGE=<workspace>/build-poky/tmp-poky/deploy/images/fvp-base-arm32/zImage - export BL1=<workspace>/build-poky/tmp-poky/deploy/images/fvp-base-arm32/bl1-fvp.bin - export FIP=<workspace>/build-poky/tmp-poky/deploy/images/fvp-base-arm32/fip-fvp.bin - export DISK=<workspace>/build-poky/tmp-poky/deploy/images/fvp-base-arm32/core-image-minimal-fvp-base-arm32.disk.img - export DTB=<workspace>/build-poky/tmp-poky/deploy/images/fvp-base-arm32/fvp-base-gicv3-psci-custom.dtb - - -Run: Pass aarch32 argument to run_model.sh - -:: - - ./run_model.sh --aarch32 - -Release Tags ------------- - -Here's the list of release tags and corresponding Fast Model version supported: - -+-----------------------+-------------------------+ -| Release Tag | Base FVP Version | -+=======================+=========================+ -| BASEFVP-2020.08.06 | 11.11.34 | -+-----------------------+-------------------------+ -| | | -+-----------------------+-------------------------+ - - --------------- - -*Copyright (c) 2020, Arm Limited. All rights reserved.* - +The basefvp platform documentation has been migrated to +https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/tree/master/docs/aemfvp-a diff --git a/docs/corstone-700/change-log.rst b/docs/corstone-700/change-log.rst index 6f1953d..2b7b3b2 100755 --- a/docs/corstone-700/change-log.rst +++ b/docs/corstone-700/change-log.rst @@ -4,6 +4,32 @@ Change Log This document contains a summary of the new features, changes and fixes in each release of Corstone-700 software stack. +Version 2020.12.10 +------------------ + +Features added +~~~~~~~~~~~~~~ +- Linux kernel version upgraded to 5.6 +- Enabled Ethernet support in linux. + (note: SMSC 91c111 in FVP and SMSC 9115 in FPGA)) +- Enabled USB host, gadget and mass support, in linux (Only for FPGA) +- Added U-boot support v2020.04 +- Trusted Firmware A upgraded to v2.3 +- Added support to configure the firewall monitor extension feature +- Using Yocto meta-arm layers aligned with Yocto Gatesgarth. +- Using Yocto poky-tiny-distro + +Changes +~~~~~~~ +- Split the FVP and FPGA into two machines. FVP and FPGA needs to be build separately. + More information can be found in the user guide. + +Fixes +~~~~~ +- Fix in the SE firewall driver to configure the regions using base and the upper + address of the regions. +- Fixed the system timer frequency for MPS3 FPGA board as 32Mhz, in TF-A code. + Version 2020.02.10 ------------------ diff --git a/docs/corstone-700/release_notes.rst b/docs/corstone-700/release_notes.rst index 2bb9670..d0df17b 100755 --- a/docs/corstone-700/release_notes.rst +++ b/docs/corstone-700/release_notes.rst @@ -1,12 +1,43 @@ -Release notes - 2020.02.10 -========================== - .. section-numbering:: :suffix: . .. contents:: +Release notes - 2020.12.10 +========================== + +Software Features +------------------ +The following is a summary of the key software features of this release: + +- Linux kernel version upgraded to 5.6 +- Enabled Ethernet support in linux. + (note: SMSC 91c111 in FVP and SMSC 9115 in FPGA) +- Enabled USB host, gadget and mass support in linux (Only for FPGA) +- Added U-boot support v2020.04 +- Trusted Firmware A upgraded to v2.3 +- Added support to configure the firewall monitor extension feature +- Using Yocto meta-arm layers aligned with Yocto Gatesgarth. +- Using Yocto poky-tiny-distro +- Detailed change log can be found in change-log.rst + +Platform Support +---------------- + - This Software release is tested on Corstone700 Fast Model platform (FVP) and FPGA + - Supported Fast model version for this release is 11.10.47 + - Supported FPGA version is AN543 V3.0 on MPS3 board + +Known Issues or Limitations +--------------------------- + + - No support for multiple transport protocols in MHUv2 driver. + It supports single word in-channel message. + +Release notes - 2020.02.10 +========================== + + Components ---------- The following is a summary of the key software features of the release: diff --git a/docs/corstone-700/user-guide.rst b/docs/corstone-700/user-guide.rst index 67333a1..8b425b0 100755 --- a/docs/corstone-700/user-guide.rst +++ b/docs/corstone-700/user-guide.rst @@ -43,8 +43,11 @@ Provided components ------------------- Within the Yocto project, each component included in the Corstone-700 software stack is specified as a `bitbake recipe <https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#recipes>`__. -The recipes specific to the Corstone-700 project may be located at: -``<corstone700_workspace>/layers/meta-corstone700``. +The recipes specific to the Corstone-700 BSP is located at: +``<corstone700_workspace>/meta-arm/meta-arm-bsp/``. +The Yocto machine conf files for the Corstone-700 is: +``<corstone700_workspace>/meta-arm/meta-arm-bsp/conf/machine/include/corstone700.inc``. + Software for Host ################# @@ -54,9 +57,9 @@ Trusted Firmware-A Based on `ARM Trusted Firmware-A <https://github.com/ARM-software/arm-trusted-firmware>`__ +--------+--------------------------------------------------------------------------------------------------+ -| Recipe | <corstone700_workspace>/layers/meta-arm/arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a.bb | +| Recipe | <corstone700_workspace>/layers/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-a | +--------+--------------------------------------------------------------------------------------------------+ -| Files | * corstone700.fip | +| Files | * fip.bin | +--------+--------------------------------------------------------------------------------------------------+ Linux @@ -68,17 +71,17 @@ which is a Linux distribution stripped down to a minimal configuration. The provided distribution is based on busybox and built using muslibc. +--------+-------------------------------------------------------------------------------+ -| Recipe | <corstone700_workspace>/layers/meta-arm/arm/recipes-kernel/linux/linux-arm.bb | +| Recipe | <corstone700_workspace>/layers/meta-arm/meta-arm-bsp/recipes-kernel/linux/ | +--------+-------------------------------------------------------------------------------+ | Files | * xipImage | -| | * iota-tiny-image-corstone700.cramfs-xip (xip rootfs) | +| | * arm-reference-image-corstone700-[fvp/mps3].cramfs-xip (xip rootfs) | +--------+-------------------------------------------------------------------------------+ Test App ******** +--------+--------------------------------------------------------------------------------------------+ -| Recipe | <corstone700_workspace>/layers/meta-arm/meta-corstone700/recipes-test/test-app/test-app.bb | +| Recipe | <corstone700_workspace>/layers/meta-arm/meta-arm-bsp/recipes-test/corstone700-test-app/ | +--------+--------------------------------------------------------------------------------------------+ | Files | * test-app (Contained within rootfs) | +--------+--------------------------------------------------------------------------------------------+ @@ -93,7 +96,7 @@ The boot firmware has ROM firmware and a RAM firmware which is based on Internally, the OpenAMP framework has been implemented, using the MHU driver as a mailbox service. +--------+-----------------------------------------------------------------------------------------------------+ -| Recipe | <corstone700_workspace>/layers/meta-arm/meta-corstone700/recipes-bsp/boot-firmware/boot-firmware.bb | +| Recipe | <corstone700_workspace>/layers/meta-arm/meta-arm-bsp/recipes-bsp/boot-firmware/ | +--------+-----------------------------------------------------------------------------------------------------+ | Files | * se_ramfw.bin | | | * se_romfw.bin | @@ -103,7 +106,7 @@ Software for External System ############################ +--------+---------------------------------------------------------------------------------------------------------+ -| Recipe | <corstone700_workspace>/layers/meta-arm/meta-corstone700/recipes-bsp/external-system/external-system.bb | +| Recipe | <corstone700_workspace>/layers/meta-arm/meta-arm-bsp/recipes-bsp/external-system | +--------+---------------------------------------------------------------------------------------------------------+ | Files | * es_flashfw.bin | +--------+---------------------------------------------------------------------------------------------------------+ @@ -111,7 +114,7 @@ Software for External System Run scripts ########### -Within ``<corstone700_workspace>/run-scripts/`` several convenience functions for testing the software +Within ``<corstone700_workspace>/run-scripts/iot/`` several convenience functions for testing the software stack may be found. Usage descriptions for the various scripts are provided in the following sections. @@ -123,27 +126,27 @@ In the top directory of the synced workspace (~/corstone700), run: :: - export DISTRO="iota-tiny" - export MACHINE="corstone700" source setup-environment + --> select corstone700-fvp or corstone700-mps3 machine based on the environment. + --> select poky-tiny By sourcing setup-environment, your current directory should now have switched to -``<corstone700_workspace>/build-iota-tiny/``. If not, change the current directory to this path. +``<corstone700_workspace>/build-poky-tiny/``. If not, change the current directory to this path. Next, to build the stack, execute: :: - bitbake iota-tiny-image + bitbake arm-reference-image The initial clean build will be lengthy, given that all host utilities are to be built as well as the target images. This includes host executables (python, cmake, etc.) and the required toolchain(s). Once the build is successful, all images will be placed in the -``<corstone700_workspace>/build-iota-tiny/tmp-iota_tiny/deploy/images/corstone700`` folder. +``<corstone700_workspace>/build-poky-tiny/tmp-poky_tiny/deploy/images/corstone700-*/`` folder. Everything apart from the ROM firmware is bundled into a single binary, the -``iota-tiny-image-corstone700.wic`` file. +``arm-reference-image-corstone700-*.wic.nopt`` file. Running the software on FVP --------------------------- @@ -154,22 +157,24 @@ The run-scripts structure is as below: :: run-scripts - |── run_model.sh - └── scripts - └── ... + |── iot + |── run_model.sh + └── scripts + └── ... Ensure that the FVP has its dependencies met by executing the FVP: ``./<Corstone-700 Model Binary>``. All dependencies are met if the FVP launches without any errors, presenting a graphical interface showing information about the current state of the FVP. -The ``run_model.sh`` script in "<corstone700_workspace>/run-scripts" folder will provide the previously built images as arguments to the FVP, and -launch the FVP. Execute the ``run_model.sh`` script: +The ``run_model.sh`` script in "<corstone700_workspace>/run-scripts/iot/" folder will provide the +previously built images as arguments to the FVP, and launch the FVP. +Execute the ``run_model.sh`` script: :: ./run_model.sh - usage: run_model.sh ${FVP executable path} [ -u ] + usage: run_model.sh ${FVP executable path/<Corstone-700 Model Binary>} [ -u ] -u: Run unit test selector No additional argument: load and execute model @@ -184,10 +189,10 @@ login using the username ``root``. Automated unit tests -------------------- -To run the included automated unit test suite, PyCADI must be available and sourced into the current +To run the included automated unit test suite, PyIRIS must be available and sourced into the current environment. -The PyCADI library is available within the Arm FastModelPortfolio package. +The PyIRIS library is available within the Arm Fast Models evaluation package. This package is shipped with most FVPs. If this has not been shipped and installed with the Corstone-700 FVP, it may be retrieved as follows: @@ -195,20 +200,20 @@ Download the Fast Models evaluation package: https://developer.arm.com/tools-and-software/simulation-models/fast-models Unzip the downloaded file and execute the ``setup.sh`` script contained within. -Once prompted for which Fast Model packages to install, tick the "Fast Model Portfolio" package. +Once prompted for which Fast Model packages to install, select all available packages. Note the installation directory. We will refer the installation directory as being -``~/ARM/FastModelsPortfolio_<version>``. +``~/ARM/FastModelsxxx_<version>``. -To make the PyCADI library available to python, the following file must be sourced into your +To make the PyIRIS library available to python, the following file must be sourced into your current environment: :: - source ~/ARM/FastModelsPortfolio_<version>/etc/setup.sh + source ~/ARM/FastModelsTools_<version>/source_all.sh For convenience, the above command may be added to your ``.bashrc`` file. -The Arm PyCADI library requires Python 2.7. +The Arm PyIRIS library requires Python 2.7. -With the PyCADI library made available in the current environment, the ``run_model.sh`` +With the PyIRIS library made available in the current environment, the ``run_model.sh`` script may now be executed with the ``-u`` argument, short for unit tests. Running the automated unit tests are done through a command line interface. This interface has the ``console-menu`` python package as a prerequisite, which may be met by the following @@ -277,10 +282,10 @@ Here is an example IMAGE2UPDATE: RAM ;Image Update:NONE/AUTO/FORCE/RAM/AUTOQSPI/FORCEQSPI IMAGE2FILE: \SOFTWARE\es_fw.bin ; - selftest uSD -OUTPUT_DIR=``<corstone700_workspace>/build-iota-tiny/tmp-iota_tiny/deploy/images/corstone700`` +OUTPUT_DIR=``<corstone700_workspace>/build-poky-tiny/tmp-poky_tiny/deploy/images/corstone700-[fvp/mps3]/`` 1. Copy se_romfw.bin from OUTPUT_DIR directory to SOFTWARE directory of the FPGA bundle -2. Copy iota-tiny-image-corstone700.wic from OUTPUT_DIR directory +2. Copy arm-reference-image-corstone700-mps3.wic.nopt from OUTPUT_DIR directory to SOFTWARE directory of the FPGA bundle and rename the wic image to cs700.wic 3. Copy es_flashfw.bin from OUTPUT_DIR directory to SOFTWARE directory of the FPGA bundle and rename es_flashfw.bin to es_fw.bin diff --git a/docs/corstone500/change-log.rst b/docs/corstone500/change-log.rst new file mode 100644 index 0000000..d352936 --- /dev/null +++ b/docs/corstone500/change-log.rst @@ -0,0 +1,49 @@ +Change Log +========== + +This document contains a summary of the new features, changes and +fixes in each release of Corstone-500. + +Version 2020.11.27 +------------------ + +Features added +~~~~~~~~~~~~~~ + +None. + +Changes +~~~~~~~ +- Branding CA5DS to Corstone-500. +- Upgrading the kernel to v5.3. +- Using Yocto meta-arm layers aligned with Yocto Gatesgarth. +- Upgrading Trusted firmware A to v2.3 with a fix for the system timer issue. +- Upgrading u-boot to 2020.07 with a fix for the generic timer MMIO access issue. + +Version 2020.03.06 +------------------ + +Features added +~~~~~~~~~~~~~~ +- Support for Snoop Control Unit and its device driver. +- Support for Cortex-A5 DesignStart on MPS3 FPGA. + +Changes +~~~~~~~ +- Changes to make the same software work on FPGA and FVP. +- Changes to Linux kernel config to run from DRAM (DDR). + +Version 2019.09.16 +------------------ + +Features added +~~~~~~~~~~~~~~ +- Platform port of Cortex-A5 DesignStart including GICv1 changes. +- Support for Arm v7 architecture in Trusted firmware A. +- Support for non-LPAE mapping in Trusted firmware A. +- Division functionality for cores that don't have divide hardware. +- Support for mmio based generic timer in u-boot. + +-------------- + +*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* diff --git a/docs/corstone500/release_notes.rst b/docs/corstone500/release_notes.rst new file mode 100644 index 0000000..e6c0796 --- /dev/null +++ b/docs/corstone500/release_notes.rst @@ -0,0 +1,41 @@ +Release notes - 2020.11.27 +========================== + +.. section-numbering:: + :suffix: . + +.. contents:: + + +Software Features +----------------- +The following is a summary of the key software features of the release: + + - Linux kernel version 5.3. + - Trusted firmware A with Corstone-500 platform port. + - U-Boot changes with memory mapped timer support. + - Build and Packaging using Yocto poky-tiny distro. + - Detailed change log can be viewed here `Change Log <change-log.rst>`__. + +Hardware Features +----------------- + + - Memory mapped generic timer support. + - Generic interrupt controller (GIC) support. + - UART PL011. + - RTC. + - Snoop Control Unit. + +Platform Support +---------------- + + - This Software release is tested on Fast Model Platform (FVP) with 4 cores. + - Supported Fast model version for this release is 11.12.59, Iris interface version 11.12. + +Support +------- +For support email: support-subsystem-iot@arm.com + +-------------- + +*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* diff --git a/docs/corstone500/user-guide.rst b/docs/corstone500/user-guide.rst new file mode 100644 index 0000000..bffc37c --- /dev/null +++ b/docs/corstone500/user-guide.rst @@ -0,0 +1,165 @@ +User Guide +========== + +.. section-numbering:: + :suffix: . + +.. contents:: + +Notice +------ +The Corstone-500 software stack uses the `Yocto project <https://www.yoctoproject.org/>`__ to build +a tiny Linux distribution. The yocto project relies on the +`Bitbake <https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html>`__ +tool as its build tool. + +Prerequisites +------------- +These instructions assume your host PC is running Ubuntu Linux 18.04 LTS. +The instructions in this document expects that you are using a bash shell. + +The following prerequisites must be available on the host system: + * chrpath + * gawk + * makeinfo + * openssl headers + * diffstat + * yocto + +To resolve these dependencies, run: + +:: + + sudo apt-get update + sudo apt-get install chrpath gawk texinfo libssl-dev diffstat wget git-core unzip gcc-multilib \ + build-essential socat cpio python python3 python3-pip python3-pexpect xz-utils debianutils \ + iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm git-lfs openssl \ + curl libncurses-dev libz-dev python-pip + + +Provided components +------------------- +Within the Yocto project, each component included in the Corstone-500 software stack is specified as +a `bitbake recipe <https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#recipes>`__. +The recipes specific to the Corstone-500 project may be located at: +``<Corstone-500_workspace>/layers/meta-arm/``. + +Software +######## + +Trusted Firmware-A +****************** +Based on `ARM Trusted Firmware-A <https://github.com/ARM-software/arm-trusted-firmware>`__. + ++--------+----------------------------------------------------------------------------------------------------------------+ +| Recipe | <Corstone-500_workspace>/layers/meta-arm/meta-arm/recipes-bsp/trusted-firmware-a/trusted-firmware-a_2.3.bb | ++--------+----------------------------------------------------------------------------------------------------------------+ +| Files | * bl1.bin | ++--------+----------------------------------------------------------------------------------------------------------------+ + +U-Boot +****** +Based on `U-Boot <git://git.denx.de/u-boot.git>`__. + ++--------+----------------------------------------------------------------------------------------------------------------+ +| Recipe | <Corstone-500_workspace>/layers/openembedded-core/meta/recipes-bsp/u-boot/u-boot_2020.07.bb | ++--------+----------------------------------------------------------------------------------------------------------------+ +| Files | * u-boot.bin | ++--------+----------------------------------------------------------------------------------------------------------------+ + +Linux +***** +The recipe responsible for building a version of Linux. +The Linux distribution used is poky-tiny which is provided by the Yocto project. +poky-tiny allows the generation of a small size linux distribution. + +`poky-tiny <https://wiki.yoctoproject.org/wiki/Poky-Tiny>`__ + +The provided distribution is based on busybox and built using musl C library. + ++--------+----------------------------------------------------------------------------------------------------------------+ +| Recipe | <Corstone-500_workspace>/layers/meta-arm/meta-arm-bsp/recipes-kernel/linux/linux-yocto_5.3.bb | ++--------+----------------------------------------------------------------------------------------------------------------+ +| Files | * zImage | +| | * arm-reference-image-corstone500.cpio.gz (rootfs) | ++--------+----------------------------------------------------------------------------------------------------------------+ + +Run scripts +########### + +Within ``<Corstone-500_workspace>/run-scripts/iot`` a number of convenience functions for testing the software +stack may be found. +Usage descriptions for the various scripts are provided in the following sections. + + +Building the Software stack +--------------------------- +Corstone-500 is a Bitbake based Yocto distro which uses bitbake commands to build the stack. +In the top directory of the synced workspace (~/Corstone-500), run: + +:: + + export DISTRO="poky-tiny" + export MACHINE="corstone500" + source setup-environment + +By sourcing setup-environment, your current directory should now have switched to +``<Corstone-500_workspace>/build-poky-tiny/``. If not, change the current directory to this path. +Next, to build the stack, execute: + +:: + + bitbake arm-reference-image + +The initial clean build will be lengthy, given that all host utilities are to be built as well as +the target images. +This includes host executables (python, cmake, etc.) and the required toolchain(s). + +Once the build is successful, all images will be placed in the deploy directory +``<Corstone-500_workspace>/build-poky-tiny/tmp-poky_tiny/deploy/images/corstone500`` folder. + +Everything apart from the BL1(ROM) binary is bundled into a single binary, the +``arm-reference-image-corstone500.wic.nopt`` file. + +Running the software on FVP +--------------------------- +An FVP (Fixed Virtual Platform) of the Corstone-500 platform must be available to execute the +included run scripts. +Also, ensure that the FVP has its dependencies met by executing the FVP: + +:: + +./<Corstone-500 Model Binary> + +All dependencies are met if the FVP launches without any errors, presenting a graphical interface +showing information about the current state of the FVP. + +The ``run_model.sh`` script in "<Corstone-500_workspace>/run-scripts/iot" folder will provide the previously built images as +arguments to the FVP and launch the FVP. + +The iot folder structure is as follows: +:: + + iot + |── run_model.sh + └── scripts + └── ... + +Execute the ``run_model.sh`` script: + +:: + + ./run_model.sh + usage: run_model.sh ${FVP executable path} [ -u ] + -u: Run unit test selector using pyIRIS + No additional argument: load and execute model + +When the script is executed, one terminal instance will be launched for the Cortex-A5 processing element. +Once the FVP is executing, relevant memory contents of the .wic.nopt file are copied to their respective +memory locations within the model, and the CPU is brought out of reset. + +The CPU will boot Linux and present a login prompt; login using the username ``root``. + +-------------- + +*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* diff --git a/docs/juno/change-log.rst b/docs/juno/change-log.rst index 381230a..d920ce5 100644 --- a/docs/juno/change-log.rst +++ b/docs/juno/change-log.rst @@ -4,6 +4,20 @@ Change Log & Release Notes This document contains a summary of the new features, changes, fixes and known issues in each release of platform software support for Juno Development Board. + +Version 21.04 (2021-Q1 release) +------------------------------- +Changed +^^^^^^^ +- Update to U-Boot version 2020.07 +- Update to yocto layers with openembedded gatesgarth branch + +Features +^^^^^^^^^ +- Yocto based Poky distro supported with u-boot version 2020.07 +- u-boot autoboot supported with default running uenvcmd + + Version 20.08 (2020-Q2 release) ------------------------------- Changed diff --git a/docs/juno/user-guide.rst b/docs/juno/user-guide.rst index 2983749..b079352 100644 --- a/docs/juno/user-guide.rst +++ b/docs/juno/user-guide.rst @@ -46,6 +46,10 @@ To resolve these dependencies, run: curl libncurses-dev libz-dev python-pip repo +Note that this software has been tested with + * repo version 2.11 + * python version 2.7 + Provided components ------------------- Within the Yocto project, each component included in the Juno software stack is specified as @@ -64,8 +68,8 @@ in these instructions mkdir <workspace> cd <workspace> - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m juno-yocto.xml -b refs/tags/JUNO-2020.08.28 - repo sync -j${nproc} + repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m juno-yocto.xml -b refs/tags/JUNO-2021.04.27 + repo sync -j$(nproc) export DISTRO="poky" export MACHINE="juno" source setup-environment @@ -114,11 +118,11 @@ U-Boot Based on `U-Boot gitlab <https://gitlab.denx.de/u-boot/u-boot>`__ -+--------+-------------------------------------------------------------------------------+ -| Recipe | <workspace>/layers/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_%.bbappend | -+--------+-------------------------------------------------------------------------------+ -| Files | * <workspace>/build-poky/tmp-poky/deploy/image/juno/u-boot.bin | -+--------+-------------------------------------------------------------------------------+ ++--------+-------------------------------------------------------------------------------------+ +| Recipe | <workspace>/layers/meta-arm/meta-arm-bsp/recipes-bsp/u-boot/u-boot_2020.07.bbappend | ++--------+-------------------------------------------------------------------------------------+ +| Files | * <workspace>/build-poky/tmp-poky/deploy/image/juno/u-boot.bin | ++--------+-------------------------------------------------------------------------------------+ Linux diff --git a/docs/n1sdp/Errata-1315703.rst b/docs/n1sdp/Errata-1315703.rst deleted file mode 100755 index 6b964c4..0000000 --- a/docs/n1sdp/Errata-1315703.rst +++ /dev/null @@ -1,29 +0,0 @@ -Errata-1315703 WA disabled in Neoverse N1 SDP -============================================= - -The patch https://git.linaro.org/landing-teams/working/arm/n1sdp-pcie-quirk.git/tree/arm-tf/0001-n1sdp-arm-tf-disable-workaround-for-N1-Erratum-13157.patch -is applied by default to the N1SDP stack to disable the workaround for Erratum 1315703 so that the N1 CPU -performance in N1SDP better reflects that of released versions of the N1 for software that does not require mitigation for Spectre Variant 4. - -N1DP uses N1 version r1p0, which is affected by Erratum 1315703, which -is fixed in N1 r3p1. The workaround for r1p0 disables the CPU performance -feature of bypassing of stores by younger loads. This can significantly -affect performance. The Erratum is classified "Cat A (Rare)" and requires -a specific sequence of events to occur. - -Disabling this CPU performance feature is also the mitigation for Spectre -Variant 4 (CVE-2018-3639). On CPUs that provide the PSTATE.SBSS feature, -the OS selectively applies the mitigation only to programs that require it, -leaving the performance of other programs unaffected. However, N1 r1p0 -does not have the PSTATE.SBSS feature (which is introduced in N1 r3p1), and -Arm-TF does not provide the interface to to dynamically disable the CPU -performance feature. Therefore, applying the workaround penalizes ALL -software running on N1 SDP, including those that do not require mitigation. - -This patch is meant for performance evaluation purposes ONLY and should not -be used for software that requires a seccomp computing environment. - --------------- - -*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* - diff --git a/docs/n1sdp/LES-PRE-21570v1.0 Neoverse N1 system development platform EULA_windows.txt b/docs/n1sdp/LES-PRE-21570v1.0 Neoverse N1 system development platform EULA_windows.txt deleted file mode 100755 index 924e935..0000000 --- a/docs/n1sdp/LES-PRE-21570v1.0 Neoverse N1 system development platform EULA_windows.txt +++ /dev/null @@ -1,272 +0,0 @@ -12 March 2019 CONFIDENTIAL LES-PRE-21570 SP-Version 1.0
-
-END USER LICENCE AGREEMENT FOR THE SOFTWARE ASSOCIATED WITH THE
-ARM® NEOVERSE™ N1 SYSTEM DEVELOPMENT PLATFORM
-
-THIS END USER LICENCE AGREEMENT (“LICENCE”) IS A LEGAL AGREEMENT BETWEEN YOU
-(EITHER A SINGLE INDIVIDUAL, OR SINGLE LEGAL ENTITY) AND ARM LIMITED ("ARM")
-FOR THE USE OF THE DELIVERABLES ACCOMPANYING THIS LICENCE. ARM IS ONLY
-WILLING TO LICENSE THE DELIVERABLES TO YOU ON CONDITION THAT YOU ACCEPT ALL
-OF THE TERMS IN THIS LICENCE. BY CLICKING “I AGREE” OR BY INSTALLING OR
-OTHERWISE USING OR COPYING THE DELIVERABLES YOU INDICATE THAT YOU AGREE TO BE
-BOUND BY ALL THE TERMS OF THIS LICENCE. IF YOU DO NOT AGREE TO THE TERMS OF
-THIS LICENCE, ARM IS UNWILLING TO LICENSE THE DELIVERABLES TO YOU AND YOU MAY
-NOT INSTALL, USE OR COPY THE DELIVERABLES, BUT YOU SHOULD PROMPTLY RETURN THE
-DELIVERABLES TO YOUR SUPPLIER AND ASK FOR A REFUND OF ANY LICENCE FEE PAID.
-
-“Hardware” means the Arm® NeoverseTM N1 System Development Platform, which is
-comprised of a hardware development board purchased or borrowed directly from
-Arm or its authorised distributors.
-
-"Deliverables" means any software, firmware, boardfiles, data and
-documentation accompanying this Licence, any printed, electronic or online
-documentation supplied with it, and any updates, patches and modifications
-Arm may make available to you under the terms of this Licence, in all cases
-relating to the supporting deliverables for the Hardware.
-
-“Purpose” means the use of the Deliverables solely for the purposes of: (1)
-your internal development, testing and debugging of software applications
-that are designed to run solely on microprocessors manufactured under licence
-from Arm; and (2) prototyping hardware designs incorporating the Deliverables
-
-
-1. LICENCE GRANTS.
-DELIVERABLES: Arm hereby grants to you, subject to the terms and conditions
-of this Licence, a non-exclusive, non-transferable licence solely for use on
-the Hardware and only for the Purpose to use and copy the Deliverables
-identified in the Schedule.
-
-You shall not modify the Deliverables. You shall not redistribute or
-sub-licence any of the Deliverables.
-
-2. RESTRICTIONS ON USE OF THE DELIVERABLES.
-COPYING: You shall not use or copy the Deliverables except as expressly
-authorised in this Licence. You may make one additional copy of the delivered
-Deliverables media or image for backup or archival purposes.
-
-PERMITTED USERS: The Deliverables shall be used only by your employees, or by
-your bona fide sub-contractors for whose acts and omissions you hereby agree
-to be responsible to Arm to the same extent as you are for any acts and
-omissions of your employees, and provided always that such sub-contractors;
-(i) work only onsite at your premises; (ii) comply with the terms of this
-Licence; (iii) are contractually obligated to use the Deliverables only for
-your benefit, and (iv) agree to assign all their work product and any rights
-they create therein in the supply of such work to you. Only the single
-individual, company or other legal entity to whom Arm is supplying this
-Licence may use the Deliverables. Except as provided in this clause, you
-shall not allow third parties (including but not limited to any subsidiary,
-parent or affiliated companies, or offsite contractors you may have) to use
-the Deliverables unless Arm specifically agrees otherwise with you on a case
-by case basis.
-
-NO REMOTE USE: The Deliverables shall only be used onsite at your premises
-and only for your benefit.
-
-MULTIPLE VERSIONS: The media on which the Deliverables resides may contain
-more than one version of the Deliverables, each of which is compatible with a
-different operating system (such as Microsoft Windows and Red Hat Linux).
-
-ACADEMIC OR EDUCATIONAL USERS ONLY: If you or your employer or institution
-paid academic or educational pricing for the Deliverables, or the
-Deliverables are identified as an academic or educational version (together
-“Academic Software”), then notwithstanding anything else in this Licence, YOU
-AGREE TO USE THE ACADEMIC SOFTWARE ONLY FOR ACADEMIC, NON-COMMERCIAL
-PURPOSES, AND ARM DOES NOT GRANT YOU ANY RIGHTS TO DISTRIBUTE OR SUB-LICENSE
-ANY APPLICATIONS DEVELOPED USING THE ACADEMIC SOFTWARE UNDER THIS LICENCE.
-
-REVERSE ENGINEERING: Except to the extent that such activity is permitted by
-applicable law you shall not reverse engineer, decompile or disassemble any
-of the Deliverables. If the Deliverables were provided to you in Europe you
-shall not reverse engineer, decompile or disassemble any of the Deliverables
-for the purposes of error correction.
-
-BENCHMARKING: This licence does not prevent you from using the Deliverables
-for internal benchmarking purposes. However, you shall treat any and all
-benchmarking data, and any other results of your use or testing of the
-Deliverables which are indicative of performance, efficacy, reliability or
-quality, as confidential information and you shall not disclose such
-information to any third party without the express written permission of Arm.
-
-RESTRICTIONS ON TRANSFER OF LICENSED RIGHTS: You shall not rent or lease the
-Deliverables. Except as identified in the “PERMITTED USERS” paragraph above,
-you shall not share the Deliverables with contractors or third parties. The
-rights granted to you under this Licence may not be assigned, sublicensed or
-otherwise transferred by you to any third party without the prior written
-consent of Arm. An assignment shall be deemed to include, without limitation;
-(i) any transaction or series of transactions whereby a third party acquires,
-directly or indirectly, the power to control the management and policies of
-you, whether through the acquisition of voting securities, by contract or
-otherwise; or (ii) the sale of more than fifty percent (50%) of the your
-assets whether in a single transaction or series of transactions. You shall
-not rent or lease the Deliverables. You shall not share the Deliverables with
-contractors (except as identified in the ‘PERMITTED USERS’ clause above) or
-other third parties.
-
-COPYRIGHT AND RESERVATION OF RIGHTS: The Deliverables are owned by Arm or its
-licensors and are protected by copyright and other intellectual property laws
-and international treaties. The Deliverables are licensed not sold. You
-acquire no rights to the Deliverables other than as expressly provided by
-this Licence. You shall not remove from the Deliverables any copyright notice
-or other notice and shall ensure that any such notice is reproduced in any
-copies of the whole or any part of the Deliverables made by you or your
-permitted users.
-
-3. SUPPORT AND MAINTENANCE.
-If you purchased the Deliverables directly from Arm, and you are not
-receiving them as an update or upgrade or as Academic Software (defined in
-Clause 2), you are entitled to reasonable support and maintenance for the
-Deliverables for the period of six (6) months from the date of purchase. The
-support will be provided on any version of the Deliverables which, at the
-date of your support request, are either; (a) the current version made
-generally available by Arm; or (b) the previous version made generally
-available by Arm at some time during the previous ninety (90) days.
-
-Support will be provided by telephone, email or other written format
-designated by Arm, prioritised at Arm’s discretion, and may not be used as a
-substitute for training or as additional resource for your programming
-projects. Maintenance will be provided in the form of upgrades, updates and
-patch releases to the Deliverables as and when they are made generally
-available from Arm.
-
-Arm’s obligation under this Clause 3 is limited to the provision of support
-and maintenance to you and Arm is under no obligation to provide any support
-and maintenance to any third parties under this Licence. If you purchase
-support and maintenance for additional years it will be provided pursuant to
-this Clause 3 and will be subject to the terms and conditions of this Licence.
-
-If you are receiving the Deliverables as an update, you obtain no rights to,
-and shall not, install or use the update, as applicable, unless you have
-first ceased all use of, and deleted your Deliverables for the version of the
-Deliverables that you are updating or upgrading, as applicable. Future
-releases of the Deliverables might introduce backward incompatible changes.
-Please refer to product documentation for the changes in each release and for
-guidance about compatibility.
-
-If; (i) you obtained the Deliverables from an Arm authorised reseller or
-other third party; (ii) Deliverables were provided free of charge or for
-evaluation; or (iii) it is Academic Software, you are not entitled to any
-support for the Deliverables from Arm, but Arm may, at its sole discretion
-provide limited support to you. The vendor of the Deliverables may or may not
-offer support to you for the Deliverables. Please refer to the Technical
-Support area of http://www.arm.com for contact details for Arm’s support
-service and (if applicable) other authorised support channels. Arm shall be
-under no obligation to provide support in respect of any modifications (where
-permitted) to the Deliverables.
-
-4. CONFIDENTIALITY.
-You acknowledge that the Deliverables, any benchmarking data and related
-information mentioned in Clause 2 contain trade secrets and confidential
-material, and you agree to maintain them in confidence and apply security
-measures no less stringent than the measures which you apply to protect your
-own like information, but not less than a reasonable degree of care, to
-prevent their unauthorised disclosure and use. Subject to any restrictions
-imposed by applicable law, the period of confidentiality shall be indefinite.
-You agree that you shall not use any such information other than in normal
-use of the Deliverables under the licences granted in this Licence. You agree
-to allow Arm to (i) disclose your confidential information to subsidiaries of
-Arm subject to terms and conditions of confidentiality substantially similar
-to those set out above in this Clause 4; and (ii) inform Arm’s partner;
-Taiwan Semiconductor Manufacturing Company Ltd, that you have entered into
-this Licence with Arm.
-
-5. LIMITED WARRANTIES.
-For the period of ninety (90) days from the date of receipt by you of the
-Deliverables, Arm warrants to you that (i) the media on which the
-Deliverables are provided shall be free from defects in materials and
-workmanship under normal use; and (ii) the Deliverables will perform
-substantially in accordance with the accompanying documentation (if any).
-Arm's total liability and your exclusive remedy for breach of these limited
-warranties shall be limited to Arm, at Arm's option; (a) replacing the
-defective Deliverables; or (b) using reasonable efforts to correct material,
-documented, reproducible defects in the Deliverables and delivering such
-corrected Deliverables to you. Any replacement Deliverables will be warranted
-for the remainder of the original warranty period or thirty (30) days,
-whichever is the longer.
-
-EXCEPT AS PROVIDED ABOVE, YOU AGREE THAT THE DELIVERABLES ARE LICENSED “AS
-IS”, AND THAT ARM EXPRESSLY DISCLAIMS ALL REPRESENTATIONS, WARRANTIES,
-CONDITIONS OR OTHER TERMS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT
-LIMITATION THE IMPLIED WARRANTIES OF NON- INFRINGEMENT, SATISFACTORY QUALITY,
-AND FITNESS FOR A PARTICULAR PURPOSE.
-
-YOU EXPRESSLY ASSUME ALL LIABILITIES AND RISKS, FOR USE OR OPERATION OF
-SOFTWARE APPLICATIONS, INCLUDING WITHOUT LIMITATION, APPLICATIONS DESIGNED OR
-INTENDED FOR MISSION CRITICAL APPLICATIONS, SUCH AS PACEMAKERS, WEAPONARY,
-AIRCRAFT NAVIGATION, FACTORY CONTROL SYSTEMS, ETC. SHOULD THE DELIVERABLES
-PROVE DEFECTIVE, YOU ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING,
-REPAIR OR CORRECTION.
-
-6. LIMITATION OF LIABILITY.
-TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL ARM BE
-LIABLE FOR ANY INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
-(INCLUDING LOSS OF PROFITS) ARISING OUT OF THE USE OR INABILITY TO USE THE
-DELIVERABLES WHETHER BASED ON A CLAIM UNDER CONTRACT, TORT OR OTHER LEGAL
-THEORY, EVEN IF ARM WAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
-ARM does not seek to limit or exclude liability for death or personal injury
-arising from ARM's negligence or ARM’s fraud or willful misconduct and
-because some jurisdictions do not permit the exclusion or limitation of
-liability for consequential or incidental damages the above limitation
-relating to liability for consequential damages may not apply to you.
-
-NOTWITHSTANDING ANYTHING TO THE CONTRARY CONTAINED IN THIS LICENCE, BUT
-SUBJECT TO THE PREVIOUS PARAGRAPH, THE MAXIMUM LIABILITY OF ARM TO YOU IN
-AGGREGATE FOR ALL CLAIMS MADE AGAINST ARM IN CONTRACT TORT OR OTHERWISE UNDER
-OR IN CONNECTION WITH THE SUBJECT MATTER OF THIS LICENCE SHALL NOT EXCEED THE
-GREATER OF; (I) THE TOTAL OF SUMS PAID BY YOU TO ARM (IF ANY) FOR THIS
-LICENCE; AND (II) $10 USD. THE EXISTENCE OF MORE THAN ONE CLAIM WILL NOT
-ENLARGE OR EXTEND THE LIMIT.
-
-7. THIRD PARTY SOFTWARE.
-The Deliverables may contain open source software, and the use of such open
-source software is expressly subject to the terms of the applicable
-license(s) for that open source software. Information about such open source
-software and applicable open source license(s) accompanies the Software.
-
-8. GOVERNMENT END USERS.
-US Government Restrictions: Use, duplication, reproduction, release,
-modification, disclosure or transfer of the Deliverables is restricted in
-accordance with the terms of this Licence.
-
-9. TERM AND TERMINATION.
-This Licence shall remain in force until terminated by you or by Arm. Without
-prejudice to any of its other rights if you are in breach of any of the terms
-and conditions of this Licence then Arm may terminate this Licence
-immediately upon giving written notice to you. You may terminate this Licence
-at any time. Upon termination of this Licence by you or by Arm: (i) you shall
-stop using the Deliverables and confidential information and destroy all
-copies of the Deliverables and confidential information in your possession
-together with all documentation and related materials; and (ii) Arm’s
-obligation to provide support and maintenance shall terminate immediately.
-The provisions of Clauses 4, 6, 7, 8, 9 and 10 shall survive termination of
-this Licence.
-
-10. GENERAL.
-This Licence is governed by English law. Except where Arm agrees otherwise
-in; (i) a written contract signed by you and ARM; or (ii) a written contract
-provided by Arm and accepted by you, this is the only agreement between you
-and Arm relating to the Deliverables and it may only be modified by written
-agreement between you and Arm. This Licence may not be modified by purchase
-orders, advertising or other representation by any person. If any clause or
-sentence in this Licence is held by a court of law to be illegal or
-unenforceable the remaining provisions of this Licence shall not be affected
-thereby. The failure by Arm to enforce any of the provisions of this Licence,
-unless waived in writing, shall not constitute a waiver of Arm's rights to
-enforce such provision or any other provision of this Licence in the future.
-
-The Deliverables provided under this Licence are subject to U.S. export
-control laws, including the U.S. Export Administration Act and its associated
-regulations, and may be subject to export or import regulations in other
-countries. You agree to comply fully with all laws and regulations of the
-United States and other countries ("Export Laws") to assure that the
-Deliverables, are not (1) exported, directly or indirectly, in violation of
-Export Laws, either to any countries that are subject to U.S.A. export
-restrictions or to any end user who has been prohibited from participating in
-the U.S.A. export transactions by any federal agency of the U.S.A.
-government; or (2) intended to be used for any purpose prohibited by Export
-Laws, including, without limitation, nuclear, chemical, or biological weapons
-proliferation.
-
-
-ARM contract references: LES-PRE-21570
-
diff --git a/docs/n1sdp/Prepare_distro_image_for_N1SDP.rst b/docs/n1sdp/Prepare_distro_image_for_N1SDP.rst deleted file mode 100755 index 4cbbaf7..0000000 --- a/docs/n1sdp/Prepare_distro_image_for_N1SDP.rst +++ /dev/null @@ -1,226 +0,0 @@ -Prepare a distro image for N1SDP: Ubuntu 18.04 as an example -============================================================ - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Introduction ------------- - -The Neoverse N1 System Development Platform (N1SDP) is an enterprise class reference board based on the Neoverse N1 core. -This document is a guide on how to prepare a Linux distro image for N1SDP platform taking Ubuntu 18.04 as an example. - -All the steps mentioned below are implemented in build-scripts provided with N1SDP Software stack. - -Building Linux Images ---------------------- - -Get Linux version 4.18 or above (5.4.0 used in this example). - -Two Linux images are required - -- Monolithic Linux image: Used during first boot -- Linux debian package: Installed by Ubuntu in first boot and used after second boot onwards. - -**Building monolithic linux image** - Apply n1sdp-pcie-quirk patches available inside <workspace/n1sdp-pcie-quirk/linux/>. - Also available here https://git.linaro.org/landing-teams/working/arm/n1sdp-pcie-quirk.git/tree/linux/ - - :: - $ export ARCH=arm64 - $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu- - $ make defconfig - $ make Image - -Generated Image name : Image - -**Building linux deb package** - -Along with the N1SDP Quirk patches get the following 5 patches from https://kernel.ubuntu.com/~kernel-ppa/mainline provided by Ubuntu and required to build linux debian package.Patches version should match with linux kernel version e.g. for 5.4 use patches under https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.4/ - -Ubuntu Patches: - - 0001-base-packaging.patch - - 0002-UBUNTU-SAUCE-add-vmlinux.strip-to-BOOT_TARGETS1-on-p.patch - - 0003-UBUNTU-SAUCE-tools-hv-lsvmbus-add-manual-page.patch - - 0004-debian-changelog.patch - - 0005-configs-based-on-Ubuntu-5.4.0-7.8.patch - -Build Commands: - :: - - $ export ARCH=arm64 - $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu- - $ cat debian.master/config/config.common.ubuntu debian.master/config/arm64/config.common.arm64 > $UBUNTU_OUT_DIR/.config - $ make oldconfig - $ sed -ie 's/CONFIG_DEBUG_INFO=y/# CONFIG_DEBUG_INFO is not set/' .config - $ make bindeb-pkg - -Generated Image name: linux-image-5.4.0+_5.4.0+-1_arm64.deb rename it to "linux-image-n1sdp.deb" - -Creating Ubuntu Root FS ------------------------------ - -Download the Ubuntu minimal root file system image from -"http://cdimage.ubuntu.com/ubuntu-base/bionic/daily/current/bionic-base-arm64.tar.gz". -This image will be extracted and modified to boot a fully fledged Ubuntu 18.04 -distro. - -An initramfs is provided containing the necessary firmware and hardware support. -The initramfs PID 1 should configure the network interface and then -execute the installation script. - -During the first boot an installation script will configure a minimal working -base-system. - -The provided installation script preforms the following tasks: - -- Set root as password for root -- Add 8.8.4.4 and 8.8.8.8 as nameservers -- Resize the second partion (and file-system) to end of disk -- Install a minimal set of package with apt-get - - -Content of the provided installation script (assumes that network is up): - :: - - #!/bin/sh - - on_exit() { - test $? -ne 0 || exit 0 - echo "something unexpected happend, bailing to a recovery shell!" >&2 - exec /bin/bash - } - - trap "on_exit" EXIT TERM - - set -u - set -e - - mount -t proc proc /proc - mount -t sysfs sysfs /sys - mount -o remount,rw / - chown -Rf root:root / || true - chmod 777 /tmp - PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin - export PATH - apt-get update - apt-get install -y \ - apt-utils \ - grub-efi-arm64 \ - ifupdown \ - initramfs-tools \ - isc-dhcp-client \ - kmod \ - linux-firmware \ - net-tools \ - openssh-server \ - resolvconf \ - sudo \ - systemd \ - udev \ - vim \ - - ln -s /dev/null /etc/systemd/network/99-default.link - echo "nameserver 8.8.4.4" >> /etc/resolvconf/resolv.conf.d/head - echo "nameserver 8.8.8.8" >> /etc/resolvconf/resolv.conf.d/head - service resolvconf restart - echo "LABEL=Ubuntu-18.04 / ext4 defaults 0 0" >> etc/fstab - echo "LABEL=ESP /boot/efi vfat defaults 0 0" >> etc/fstab - mkdir /boot/efi - mount /boot/efi - grub-install || true - [ -e /linux-image-n1sdp.deb ] && dpkg -i /linux-image-n1sdp.deb - [ -e /linux-headers-n1sdp.deb ] && dpkg -i /linux-headers-n1sdp.deb - sed -ie 's/^GRUB_TIMEOUT_STYLE=.*$/GRUB_TIMEOUT_STYLE=menu/; s/^GRUB_TIMEOUT=.*$/GRUB_TIMEOUT=2/; s/GRUB_CMDLINE_LINUX_DEFAULT=.*$/GRUB_CMDLINE_LINUX_DEFAULT="earlycon vfio-pci.ids=10ee:9038"/' /etc/default/grub - update-grub - sync - # change root password - echo "root:root" | chpasswd - # Create user ubuntu:ubuntu - adduser ubuntu --gecos "ubuntu" --disabled-password - echo "ubuntu:ubuntu" | chpasswd - usermod -aG sudo ubuntu - cat <<EOF >/etc/modprobe.d/vfio.conf - # cat /etc/modprobe.d/vfio.conf - options vfio-pci ids=10ee:9038 - softdep radeon pre: vfio-pci - softdep amdgpu pre: vfio-pci - softdep nouveau pre: vfio-pci - softdep drm pre: vfio-pci - options kvm_amd avic=1 - EOF - update-initramfs -u - cat <<EOF >/etc/modules-load.d/vfio-pci.conf - # cat /etc/modules-load.d/vfio-pci.conf - vfio-pci - EOF - sync - -Content of /etc/network/interfaces - :: - - #!/bin/sh - # Network setup - # interfaces(5) file used by ifup(8) and ifdown(8) - auto eth0 - iface eth0 inet dhcp - - -Creating Ubuntu disk Image --------------------------- -- Create "grub-ubuntu.img" disk image which will have two partitions, first a - FAT partition of 20MB and second an EXT4 partiton of 4GB. - -- FAT partition labeled as ESP which contains grub configuration for **first** boot. - :: - - set debug="loader,mm" - set term="vt100" - set default="0" - set timeout="1" - - set root=(hd1,msdos2) - - menuentry 'Install Ubuntu on N1SDP Platform' { - linux /Image acpi=force earlycon=pl011,0x2A400000 - initrd /ramdisk.img - } - -- EXT4 partition labeled as Ubuntu-18.04 which contains extracted Ubuntu-18.04 - root file system created earlier along with both kernel images and initramfs. - -Mounting of disk Image on memory stick --------------------------------------- - :: - - $ lsblk - $ sudo dd if=grub-ubuntu.img of=/dev/sd<X> bs=1M - $ sync - -Note: Replace ``/dev/sdX`` with the handle corresponding to your USB stick as identified by the ``lsblk`` - -Booting Sequence ----------------- -**First Boot** - -- The GRUB configuration stored on the ESP partition is used -- The monolithic kernel image and initramfs are used -- /init configures the network and mount the real root -- /init executes the installation script -- The installation script installs the base packages -- The installation script installs the Linux deb package and creates a - new initramfs and grub entry - -**Second Boot** - -- Second boot onwards a minimal Ubuntu-18.04 will be booted which already has a grub entry created during first boot. -- It will also use linux debian image and initramfs installed during first boot. - --------------- - -*Copyright (c) 2020, Arm Limited. All rights reserved.* - diff --git a/docs/n1sdp/ccix-accelerator.rst b/docs/n1sdp/ccix-accelerator.rst deleted file mode 100755 index a2042df..0000000 --- a/docs/n1sdp/ccix-accelerator.rst +++ /dev/null @@ -1,119 +0,0 @@ -CCIX Accelerator support on Neoverse N1SDP -========================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -CCIX Overview -------------- -Cache Coherent Interconnect for Accelerators (CCIX) is an architecture for data -sharing between a host(N1SDP) and peripheral attached memory and accelerators -connected to the CCIX aware PCIe Slot. CCIX provides coherency between -accelerators, processors and memory, enabling seamless data movement among them. -The CCIX architecture relieves the operating system, or drivers, from having to -execute cache management operations in either processor or accelerator caches, -when data is being shared between them. - -For detailed description refer to `CCIX-consortium`_ to get the CCIX base -specification and software guide. - -The CCIX PoC (Proof of Concept) software framework for N1SDP is based on the -Alveo-U280 FPGA and reliant on bit files and software deliverables from Xilinx. -These components are are not included in this release. Please contact Xilinx for -more information and for Alveo-U280 specific support issues using `Xilinx-Lounge`_ - -Alveo U280 card Installation ----------------------------- - -**Prerequisites** - -The following hardware is required - - N1SDP as the host - - Xilinx Alveo U280 as the Accelerator Card - -**Connect Alveo U280 card to N1SDP** - -Follow the below steps to connect the Alveo U280 on N1SDP board: - 1. Switch off the SMPS switch on N1SDP to power off the board. - 2. Connect the Alevo U280 into the CCIX Slot. - 3. Connect power supply to the Alveo U280. Refer to `Xilinx-Lounge`_ on how - to connect power supply to the card. - 4. Connect a micro USB cable between the Alveo U280 and the host preferably - an x86 Ubuntu machine. - 5. Ensure software tools required by Alveo U280 are installed on the Host - machine. Refer to `Xilinx-Lounge`_ on how to install them. - -**Flash bitfiles on Alveo U280 Card** - - 1. Refer to `Xilinx-Lounge`_ to power on Alveo U280 card. - 2. Refer to `run-on-n1sdp`_ to power ON the N1SDP board. - 3. Refer to `Xilinx-Lounge`_ to program the bitfiles on Alveo U280. - 4. Once the bitfiles have been flashed reboot the N1SDP board using - ``REBOOT`` command in MCC console. - -How to build CCIX on N1SDP ---------------------------- -Refer to the `user-guide`_ to sync the software stack. Select the appropriate -option for CCIX accelerator usecase while syncing the software stack through the -sync script. -Refer to `Xilinx-Lounge`_ to apply patches on the stack required for the bitfile. -Refer to `run-on-n1sdp`_ to build the software stack. - -Verification of CCIX Accelerator Framework ------------------------------------------- -Refer to `run-on-n1sdp`_ to boot the N1SDP board. Once the board has booted edit -the file /etc/default/grub. Add pcie_acs_override=id:13b5:0100 option to the -GRUB_CMDLINE_LINUX_DEFAULT. Save this file and run update-grub command. - -Install the below utility if not already present:: - - $ apt-get install memtester - -If the bit file has only Request Agent(RA), then there can be two traffic flows -which can be tested. These are: - - 1. Host RA to Host HA - 2. Remote RA to Host HA - -The above traffic flows are described in detail below. - -**Host RA to Host HA** - -This is the traffic within the host(N1SDP) and the traffic flow happens between -Host RA and Host HA. This can be tested with the following command:: - - $ memtester 1M 1 - -In the above command, memtester utility is used to allocate and stress test 1 MB -of memory once. Refer to the memtester linux man page for the list of supported -options. - -**Remote RA to Host HA** - -This is the traffic between the Host(N1SDP) and Remote(Alveo U280) and the -traffic flow happens between Remote RA and Host HA. This can be tested with the -following commands for the relevant bitfiles:: - - $ ./bind_tst -n <VFIO_ID> - $ ./pri_tst -n <VFIO_ID> - -Refer `Xilinx-Lounge`_ to get the binaries *<bind_tst>*, *<pri_tst>* and source code -of the proprietary test applications along with the *<VFIO_ID>* to be used for the -relevant bitfiles. - -References ----------- -- http://infocenter.arm.com/help/topic/com.arm.doc.101489_0000_01_en/arm_neoverse_n1_system_development_platform_technical_reference_manual_101489_0000_01_en.pdf - -.. _CCIX-consortium: https://www.ccixconsortium.com/ccix-library/ -.. _Xilinx-Lounge: https://www.xilinx.com/member/ccix.html - ----------- - -*Copyright (c) 2020, Arm Limited. All rights reserved.* - -.. _user-guide: ../../user-guide.rst -.. _run-on-n1sdp: ../run-on-n1sdp.rst diff --git a/docs/n1sdp/change-log.rst b/docs/n1sdp/change-log.rst index 7e81eba..9363b9c 100755 --- a/docs/n1sdp/change-log.rst +++ b/docs/n1sdp/change-log.rst @@ -9,6 +9,29 @@ Change Log This document contains a summary of the incremental features, changes, fixes and known issues in each release of N1SDP stack. It is listed in the order of latest to oldest +Tagged Version - N1SDP-2020.12.15 +---------------------------------------- +New Features +^^^^^^^^^^^^ +- Yocto based BSP build to generate Poky image. +- Streamlining of build-scripts to build only ubuntu image and perf package. Use yocto framework for other components. +- Enable PCIe devices on secondary chip. +- Migrate to scp-v2.7 to fix the system shutdown on reaching temperature threshold. + +Known Issues and Limitations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +- If either of the two boards needs to boot-up in a single chip mode with a C2C setup, + then the other board should be powered off. +- PCIe root port is limited to GEN3 speed due to the on-board PCIe switch itself only supporting + upto GEN3 speed. +- Page Request Interface (PRI) feature is not available in both SMMUs interfacing with the + PCIe root ports. +- Currently only Micron 8GB single Rank DIMM (part number: MTA9ASF1G72PZ-2G6D1) and + 16GB dual Rank DIMMs (part number:MTA18ASF2G72PDZ-2G6E1) are supported. +- Stability issues have been observed on long stress tests of the system. +- On-board HDMI connection is not supported for graphics output. A PCIe graphics card can be used + for graphics support. + Tagged Version - N1SDP-2020.07.27 ---------------------------------------- New Features @@ -52,7 +75,7 @@ New Features - Multichip SMP support over CCIX/PCIe link. - Dual socket SMP boot with two N1SDP boards connected over CCIX/PCIe link. - - Linux sees 8 cores and DDR memories from both master and slave N1SDP boards. + - Linux sees 8 cores and DDR memories from both primary and secondary N1SDP boards. - CCIX/PCIe link running at GEN3 x16 speed. - PCIe GEN4 x16 support in CCIX slot. GEN4 x16 link verified with Mellanox Card (MCX516A-CDAT). diff --git a/docs/n1sdp/cmn-performance-analysis.rst b/docs/n1sdp/cmn-performance-analysis.rst deleted file mode 100644 index 96c4740..0000000 --- a/docs/n1sdp/cmn-performance-analysis.rst +++ /dev/null @@ -1,363 +0,0 @@ -CMN-600 perf example on Neoverse N1 SDP -======================================= -The goal of this document is to give a short introduction on CMN-600 -performance analysis on N1SDP. -This includes driver load verification and Linux perf usage examples. - -The examples include examples such as system level cache access and traffic to -and from PCI-E devices from the view of the interconnect. - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Support in Arm's Neoverse N1 SDP software release -------------------------------------------------- -The software support for CMN-600 performance analysis can be divided into three -components: - -* The user space Linux perf tool -* The Linux kernel arm-cmn driver -* EDK2 (DSDT table entry) - -The default build of the supplied Neoverse software stack will include all -necessary changes and patches to test and explore CMN-600 performance analysis. - - -CMN-600 Topology and NodeIDs on Neoverse N1 SDP ------------------------------------------------ -The PMUs in CMN-600 are distributed to the nodes of the mesh interconnect. -NodeType specific events are configured per node. -Event counting is done by local counters in the XP attached to the node. -Global counters are in the Debug Trace Controller (DTC). -The arm-cmn driver uses local/global register pairing to provide 64-bit event -counters (see "Counter Allocation" section below). - -All the nodes are referenced by NodeID and NodeType. -PMU events must specify the NodeID of the node on which it is to be counted -using the nodeid= parameter. -A summary of Node ID can be found the table below. -For more details contact support (support-subsystem-enterprise@arm.com). - -+---------------------------------+-----------+---------+--------------------+ -| Purpose | Node Type | Node ID | Event Name | -+---------------------------------+-----------+---------+--------------------+ -| System-Level Cache slices (SLC) | HNF | 0x24 | arm_cmn/hnf | -| | | 0x28 | | -| | | 0x44 | | -| | | 0x48 | | -+---------------------------------+-----------+---------+--------------------+ -| PCI_CCIX (Expansion slot 4) | RND | 0x08 | arm_cmn/rnid | -+---------------------------------+-----------+---------+--------------------+ -| PCI_0 (All other PCI-E) | RND | 0x0c | arm_cmn/rnid | -+---------------------------------+-----------+---------+--------------------+ -| Mesh interconnections | XP | 0x00 | arm_cmn/mxp | -| | | 0x08 | | -| | | 0x20 | | -| | | 0x28 | | -| | | 0x40 | | -| | | 0x48 | | -| | | 0x60 | | -| | | 0x68 | | -+---------------------------------+-----------+---------+--------------------+ -| Debug Trace Controller | DTC | 0x68 | arm_cmn/dtc_cycles | -+---------------------------------+-----------+---------+--------------------+ -| ACE-lite slave | SBSX | 0x64 | arm_cmn/sbsx | -+---------------------------------+-----------+---------+--------------------+ - -For details on what is connected to PCI_0 check the N1SDP TRM (Figure 2-9 -PCI Express and CCIX system). - -Software components -------------------- - -Linux perf tool -############### -No modifications of ``perf`` source is needed. -The user can opt to use any perf compatible with the built kernel or use the -included script ``build-scripts/build-perf.sh`` to build a static linked binary -from the included kernel source (binary is created as -``output/n1sdp/build_artifact/perf``). - - -ACPI DSDT modification -###################### -The Linux driver expects a DSDT entry that describe the location of the CMN-600 -configuration space. -This is included in the supplied Neoverse software stack. - -Linux perf driver (arm-cmn) -########################### -The included arm-cmn driver is a work-in-progress. -A Snapshot of this driver is included in the supplied Neoverse software stack. -The driver is controller by ``CONFIG_ARM_CMN`` (enabled in default software -stack build). - -Counter Allocation/Limitation -***************************** -The arm-cmn driver provides 64-bit event counts for any given event. -It accomplishes this using a combination of combined-pair local counters (in an -DTM/XP) and (uncombined) global counters (in the DTC): - -* DTM/XP - Can provide up to two 32-bit local counters (built from paired 16-bit - counters por_dtm_pmevcnt0+1, and 2+3) for events from itself and/or the - up-to-2 devices that are connected to its ports. - - Overflows from these counters are sent to its DTC's global counters. - This means only up to 2 events from any of the devices connected to an XP - can be counted at the same time without sampling. - - -* DTC - Each DTC can provide up to 8 global counters (por_dt_pmevcntA .. H). - This means only up to 8 events in a DTC domain can be counted at the same - time without sampling. - -For example, the N1SDP's two PCI-Express root complexes' RND (PCI_CCIX on RND3 -at NodeID 0x8 and PCI0 on RND4 at NodeID 0xC), hang off of the same XP (0,1). -Only up to 2 RND events from either of the two PCI-E domains can be measured -simultaneously without sampling; 3 or more will require sampling. - -In the following example, we try to measure 4 RND events, but perf is only -giving 50% sampling time for each count because the events have to share local -counters in the XP. -:: - - $ perf stat -a \ - -e arm_cmn/rnid_txdat_flits,nodeid=8/ \ - -e arm_cmn/rnid_txdat_flits,nodeid=12/ \ - -e arm_cmn/rnid_rxdat_flits,nodeid=8/ \ - -e arm_cmn/rnid_rxdat_flits,nodeid=12/ \ - -I 1000 - # time counts unit events - 1.000089438 0 arm_cmn/rnid_txdat_flits,nodeid=8/ (50.00%) - 1.000089438 0 arm_cmn/rnid_txdat_flits,nodeid=12/ (50.00%) - 1.000089438 0 arm_cmn/rnid_rxdat_flits,nodeid=8/ (50.00%) - 1.000089438 0 arm_cmn/rnid_rxdat_flits,nodeid=12/ (50.00%) - 2.000231897 79 arm_cmn/rnid_txdat_flits,nodeid=8/ (50.01%) - 2.000231897 0 arm_cmn/rnid_txdat_flits,nodeid=12/ (50.01%) - 2.000231897 0 arm_cmn/rnid_rxdat_flits,nodeid=8/ (49.99%) - -PMU Events -********** -``perf list`` shows the perfmon events for the node types that are detected by -the arm-cmn driver. -If a node type is not detected, perf list will not show the events for that -node type. -:: - - # perf list | grep arm_cmn/hnf - arm_cmn/hnf_brd_snoops_sent/ [Kernel PMU event] - arm_cmn/hnf_cache_fill/ [Kernel PMU event] - arm_cmn/hnf_cache_miss/ [Kernel PMU event] - arm_cmn/hnf_cmp_adq_full/ [Kernel PMU event] - arm_cmn/hnf_dir_snoops_sent/ [Kernel PMU event] - arm_cmn/hnf_intv_dirty/ [Kernel PMU event] - arm_cmn/hnf_ld_st_swp_adq_full/ [Kernel PMU event] - arm_cmn/hnf_mc_reqs/ [Kernel PMU event] - arm_cmn/hnf_mc_retries/ [Kernel PMU event] - [...] - -The perfmon events are described in the CMN-600 TRM in the register description -section for each node type's perf event selection register (at offset 0x2000 of -each node that has a PMU). - -CMN-600 TRM register summary (links to all of the node types' offset registers). - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100180_0201_00_en/bry1447971081070.html - - -Specifying NodeID to events in perf -*********************************** -To program the CMN-600's PMUs, the NodeIDs of the components need to be -specified for each event using a nodeid= parameter. -Example: -:: - - $ perf stat -a -I 1000 -e arm_cmn/hnf_mc_reqs,nodeid=0x24/ - - -Multiple nodes can be specified for an event using bash brace expansion. -Note the comma after the -e. -:: - - $ perf stat -a -I 1000 \ - -e,arm_cmn/hnf_mc_reqs,nodeid={0x24,0x28,0x44,0x48}/ - - -Separate events on the same nodes with brace expansion should be specified -using separate -e. -:: - - $ perf stat -a -I 1000 \ - -e,arm_cmn/hnf_mc_reqs,nodeid={0x24,0x28,0x44,0x48}/ \ - -e,arm_cmn/hnf_mc_retries,nodeid={0x24,0x28,0x44,0x48}/ - -Note this form requires the trailing '/' at the end of the event name. - - -Driver verification -------------------- -To verify that the arm-cmn has successfully loaded different ways: - -* Check if any arm_cmn entires is available - :: - - $ perf list | grep arm_cmn - arm_cmn/dn_rxreq_dvmop/ [Kernel PMU event] - arm_cmn/dn_rxreq_dvmop_vmid_filtered/ [Kernel PMU event] - arm_cmn/dn_rxreq_dvmsync/ [Kernel PMU event] - arm_cmn/dn_rxreq_retried/ [Kernel PMU event] - arm_cmn/dn_rxreq_trk_occupancy_all/ [Kernel PMU event] - arm_cmn/dn_rxreq_trk_occupancy_dvmop/ [Kernel PMU event] - [...] - - -* Sysfs entries - :: - - $ ls -x /sys/bus/event_source/devices/arm_cmn/ - cpumask - dtc_domain_0 - events - format - perf_event_mux_interval_ms - power - subsystem - type - uevent - - -Example -------- - -HN-F PMU -######## -Make sure to issue some memory load operation(s) in parallel, such as -memtester, while executing the following perf example. - -Memory Bandwidth using hnf_mc_reqs -********************************** -Measure memory bandwidth using hnf_mc_reqs; assumes bandwidth comes from SLC -misses. -:: - - $ perf stat -e,arm_cmn/hnf_mc_reqs,nodeid={0x24,0x28,0x44,0x48}/ -I 1000 -a - 2.000394365 121,713,206 arm_cmn/hnf_mc_reqs,nodeid=0x24/ - 2.000394365 121,715,680 arm_cmn/hnf_mc_reqs,nodeid=0x28/ - 2.000394365 121,712,781 arm_cmn/hnf_mc_reqs,nodeid=0x44/ - 2.000394365 121,715,432 arm_cmn/hnf_mc_reqs,nodeid=0x48/ - 3.000644408 121,683,890 arm_cmn/hnf_mc_reqs,nodeid=0x24/ - 3.000644408 121,685,839 arm_cmn/hnf_mc_reqs,nodeid=0x28/ - 3.000644408 121,682,684 arm_cmn/hnf_mc_reqs,nodeid=0x44/ - 3.000644408 121,685,669 arm_cmn/hnf_mc_reqs,nodeid=0x48/ - - -Generic bandwith formula: -:: - - hnf_mc_reqs/second/hnf node * 64 bytes = X MB/sec - -Subsitute with data from perf output: -:: - - (121713206 + 121715680 + 121712781 + 121715432) * 64 = 29715 MB/sec - - - -PCI-E RX/TX bandwidth -##################### -The RN-I/RN-D events are defined from the perspective of the bridge to the -interconnect, so the "rdata" events are outbound writes to the PCI-E device -and "wdata" events are inbound reads from PCI-E. - -Measure RND (PCI-E) bandwidth to/from NVMe SSD when running fio -*************************************************************** -The NVMe SSD (Optane SSD 900P Series) is on PCI-E Root Complex 0 (PCI0, the -Gen3 slot, behind the PCI-E switch). - -Run ``fio`` to read from NVME SSD using 64KB block size for 1000 seconds in -one terminal: -:: - - $ fio \ - --ioengine=libaio --randrepeat=1 --direct=1 --gtod_reduce=1 \ - --time_based --readwrite=read --bs=64k --iodepth=64k --name=r0 \ - --filename=/dev/nvme0n1p5 --numjobs=1 --runtime=10000 - r0: (g=0): rw=read, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=65536 - fio-3.1 - Starting 1 process - ^Cbs: 1 (f=1): [R(1)][0.5%][r=2586MiB/s,w=0KiB/s][r=41.4k,w=0 IOPS][eta 16m:35s] - fio: terminating on signal 2 - - r0: (groupid=0, jobs=1): err= 0: pid=1443: Thu Dec 19 12:12:10 2019 - read: IOPS=41.3k, BW=2581MiB/s (2706MB/s)(12.3GiB/4894msec) <------------------------------- read bandwidth = 2706 MB/sec - bw ( MiB/s): min= 2276, max= 2587, per=98.10%, avg=2532.02, stdev=125.43, samples=6 - iops : min=36418, max=41392, avg=40512.33, stdev=2006.90, samples=6 - cpu : usr=3.15%, sys=35.15%, ctx=16686, majf=0, minf=1049353 - IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0% - submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% - complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1% - issued rwt: total=202101,0,0, short=0,0,0, dropped=0,0,0 - latency : target=0, window=0, percentile=100.00%, depth=65536 - - Run status group 0 (all jobs): - READ: bw=2581MiB/s (2706MB/s), 2581MiB/s-2581MiB/s (2706MB/s-2706MB/s), io=12.3GiB (13.2GB), run=4894-4894msec - - Disk stats (read/write): - nvme0n1: ios=202009/2, merge=0/19, ticks=4874362/51, in_queue=3934760, util=98.06% - -Measure with ``perf`` in an other terminal. -Measure rdata/wdata beats. Each beat is 32 bytes. -:: - - $ perf stat -e,arm_cmn/rnid_s0_{r,w}data_beats,nodeid=0xc/ -I 1000 -a - 3.000383383 248,145 arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/ - 3.000383383 84,728,162 arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/ - 4.000522271 248,199 arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/ - 4.000522271 84,743,908 arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/ - 5.000680779 248,209 arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/ - 5.000680779 84,746,976 arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/ - 6.000835927 247,899 arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/ - 6.000835927 84,417,098 arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/ - -Calculate read bandwidth from perf measurement: -:: - - 84.74e6 wdata beats * 32 bytes per beat = 2711 MB/sec - -Measure RND (PCI-E) bandwidth from Ethernet NIC -*********************************************** -``netperf`` is executed on the N1SDP to generate network traffic. - -``netperf`` executing in on terminal... -:: - - $ netperf -D 10 -H remote-server-in-astlab -t TCP_MAERTS -l 0 - Interim result: 941.52 10^6bits/s over 10.000 seconds ending at 1576269135.608 - Interim result: 941.52 10^6bits/s over 10.000 seconds ending at 1576269145.608 - Interim result: 941.52 10^6bits/s over 10.000 seconds ending at 1576269155.608 - Interim result: 941.52 10^6bits/s over 10.000 seconds ending at 1576269165.608 - -...and ``perf`` in an other at the same time. -:: - - $ perf stat -e,arm_cmn/rnid_s0_{r,w}data_beats,nodeid=0xc/ -I 1000 -a - 12.001904404 308,803 arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/ - 12.001904404 4,024,328 arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/ - 13.002047284 308,994 arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/ - 13.002047284 4,024,287 arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/ - 14.002233364 309,035 arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/ - 14.002233364 4,024,470 arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/ - 15.002390125 309,162 arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/ - 15.002390125 4,024,376 arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/ - -Calculate bandwidth from perf measurement: -:: - - 4.024e6 wdata beats/second * 32 bytes/beat * 8 bits/byte = 1030e6 bits/second - - -*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* diff --git a/docs/n1sdp/coresight.rst b/docs/n1sdp/coresight.rst deleted file mode 100755 index 8744c3b..0000000 --- a/docs/n1sdp/coresight.rst +++ /dev/null @@ -1,160 +0,0 @@ -CoreSight support on Neoverse N1 SDP -==================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -CoreSight Introduction ----------------------- -CoreSight Debug and Trace components are invariably described in a graph-like -topology which describes the port connections amongst the various components. -The topology includes, but is not limited to, the following major components. - -* ETM(s) -* ETF(s)/ETB(s) -* Dynamic/Static Funnel(s) -* Dynamic/Static Replicator(s) -* TPIU(s)/ETR(s) - -In CoreSight terminology, a component can be roughly described as a source - -that produces/generates the debug & trace data, and/or a sink - that consumes/stores -the data, or a link - which routes the data. -Depending on the "type" of component, it may have 1 or more input port(s), -1 or more output port(s), a single input port only, or a single output port only. - -For instance - - -* ETM is a source component which only has a single output port. -* TPIU/ETR is a sink component which only has a single input port. -* Funnel is a link component which can be thought of as a MUX having multiple - input ports and a single output port. -* Replicator is a link component which can be thought of as a DEMUX having a single - input port and multiple output ports. -* ETF is a link component which can act both as a source and a sink (it has a - FIFO buffer to store the data) and thus has a single input and a single output port. - -Refer to `CoreSight_Technical_Introduction`_ for more information about -CoreSight Debug and Trace elements. - -It is worth mentioning that all static components in CoreSight world are not -addressable and only facilitate intermediate connections between the other -non-static/Dynamic CoreSight components. They are, however, described in the -DT/ACPI and get discovered by their respective kernel drivers. - -CoreSight components can be described either/both in a device tree or/and in a -DSDT table within ACPI - similar to other components/peripherals, to get -enumerated by the Linux kernel. - -Every CoreSight component has a corresponding kernel driver which takes care of -its initialization. There are configuration changes required in the kernel to -build the appropriate CoreSight components' drivers. - -Upon a successful probe of a CoreSight component driver, the particular -component gets enumerated under ``/dev`` and appears under ``/sys/bus/coresight/devices/`` -in the booted kernel. - -Enabling CoreSight on N1SDP ---------------------------- - -* ACPI bindings: - - CoreSight topology for N1SDP has been described as a _DSD graph within DSDT - table for N1SDP package - the support is enabled by default. - - -* Linux Kernel: - - The default configuration for the kernel is to build without the CoreSight drivers. - The build flag to enable CoreSight kernel configuration options to build CoreSight - kernel drivers is ``LINUX_CORESIGHT_BUILD_ENABLED`` which is set to ``0`` by default. - Modify the file ``n1sdp`` under ``build_scripts/platforms/n1sdp`` by setting - ``LINUX_CORESIGHT_BUILD_ENABLED`` to ``1`` from its default ``0``. - -Verifying CoreSight support ---------------------------- - -Assuming the kernel has been built with the CoreSight configuration, the booted -kernel should have CoreSight components enumerated under sysfs within -``/sys/bus/coresight/devices/``. The components should also be seen listed under ``/dev``. - -Running perf with CoreSight ---------------------------- - -CoreSight framework has been integrated with the standard perf core in the kernel -to assist with trace capturing and decoding. To exercise this, perf needs to be -built with openCSD (Open CoreSight Decoding) library support. - -Execute the following script to build the perf executable with open CSD library - - :: - - ./build-scripts/build-perf.sh - -This will generate the perf executable in the output/n1sdp/build_artifact/ directory which -can then be transferred to the kernel running on the N1SDP board. - -Here's an example showcasing trace capture and decode of a simple application: - -1. Build the demo application code: - - *aarch64-linux-gnu-gcc -static -o test main.c* - -.. code-block:: - - #include <stdio.h> - - int main() - { - printf("N1SDP\n"); - - return 0; - } - -2. Disassemble the binary: - - *aarch64-linux-gnu-objdump test.out* - -.. code-block:: - - 0000000000400580 <main>: - 400580: a9bf7bfd stp x29, x30, [sp,#-16]! - 400584: 910003fd mov x29, sp - 400588: 90000000 adrp x0, 400000 <_init-0x3b0> - 40058c: 9118e000 add x0, x0, #0x638 - 400590: 97ffffa4 bl 400420 <puts@plt> - 400594: 52800000 mov w0, #0x0 - 400598: a8c17bfd ldp x29, x30, [sp],#16 - 40059c: d65f03c0 ret - -3. Trace the application from the start address ``0x400580`` to ``0x4006f0`` - - *./perf record -e cs_etm/@tmc_etr0/u --filter 'start 0x400580@test, stop 0x4006f0@test' --per-thread ./test* - - This step will generate *perf.data* in the current working directory. - -4. Decode the trace data with perf - - *./perf report --stdio --dump* - - This step will dump all the captured trace data on stdio. - -Refer to the man page of ``perf-record`` for more information on perf options, filters, etc. - -References ----------- - -- http://infocenter.arm.com/help/topic/com.arm.doc.epm039795/coresight_technical_introduction_EPM_039795.pdf?_ga=2.263237196.1385850732.1581332707-419757503.1576059061 -- http://infocenter.arm.com/help/topic/com.arm.doc.101489_0000_01_en/arm_neoverse_n1_system_development_platform_technical_reference_manual_101489_0000_01_en.pdf -- https://www.linaro.org/blog/stm-and-its-usage/ - - -.. _CoreSight_Technical_Introduction: http://infocenter.arm.com/help/topic/com.arm.doc.epm039795/coresight_technical_introduction_EPM_039795.pdf?_ga=2.263237196.1385850732.1581332707-419757503.1576059061 - --------------- - - -*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* - diff --git a/docs/n1sdp/multichip.rst b/docs/n1sdp/multichip.rst deleted file mode 100755 index 685d3af..0000000 --- a/docs/n1sdp/multichip.rst +++ /dev/null @@ -1,117 +0,0 @@ -Multichip SMP boot on Neoverse N1 SDP with CCIX -=============================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Introduction ------------- -The Neoverse N1 System Development Platform (N1SDP) supports dual socket operation wherein -two N1SDP boards are connected over a CCIX enabled PCIe link. One board is designated as the -master board whose CCIX enabled PCIe controller is configured in root port mode and the other -board is configured as slave board whose CCIX enabled PCIe controller is configured in -endpoint mode. Linux boots in the master board and powers ON the slave board cores such that -the operating system sees CPU cores and memories from both master and slave boards in separate -NUMA nodes making a dual socket SMP configuration. - -Note: -Only cores and DDR memory from slave chip are exposed to the operating system. No I/O peripherals -from slave chip are exposed to the operating system. - -Connection Details ------------------- -For the purpose of connecting two N1SDP boards over PCIe link, a specialized PCIe riser card -(Part No: V2M-N1SDP-0343A) has to be used. The riser card package includes two PCIe form factor -riser cards, two high speed low latency PCIe cables and one USB cable (for PCIe REFCLK). -A 20-pin flat ribbon cable that comes along with N1SDP board accessories should also be used. This -is used for I2C connection between master and slave board SCP & MCP and other timer synchronization -handshake signals. -Setup has to be made following the steps given below: - - 1. Designate one N1SDP board as master board and the other N1SDP board as slave board. - 2. Ensure that both board are powered off. - 3. Plug in the riser cards, one in each board, in the CCIX slot (the last x16 PCIe slot - close to the edge of the board). - 4. Connect the high speed PCIe cables between the riser cards in respective slots - (make one to one connection and not criss-cross connection). - 5. Connect the USB cable between the riser cards. - 6. Connect the 20-pin flat ribbon cable between the boardsto the connector named as 'C2C' - which should be in the back side of the board. - 7. Connect the USB/SATA boot media to the respective slot in the master board. - -Board Files Setup ------------------ - 1. Power ON the master board and open the MCC console of master board using a terminal - application (like minicom or putty). - 2. Run USB_ON command which mounts the micro SD card content of master board in host machine. - 3. Assuming the micro SD card is mounted with the name 'MASTER' in host. Open the file - MASTER/MB/HBI0316A/board.txt file and note the APPFILE name. It should be like 'io_v123f.txt' - or similar. - 4. Now close the board.txt file and open the io_v123f.txt (the one noted in step 3) which will - be in the same folder. - 5. Set the C2C_ENABLE flag as TRUE and C2C_SIDE flag as MASTER. - 6. Set the SCC PLATFORM_CTRL register to enable multichip mode and CHIPID=0. For this, uncomment - the SOCCON with offset 0x1170 and set the value 0x00000100 - The line should now read: **SOCCON: 0x1170 0x00000100 ; SoC SCC PLATFORM_CTRL** - 7. Save and close the file. If the host is Linux run a 'sync' command in one of the terminals to - be safe. - 8. Repeat from step 1 to 4 for slave board. Let's assume host has mounted the slave board's - micro SD card with name 'SLAVE'. - 9. Set the C2C_ENABLE flag as TRUE and C2C_SIDE flag as SLAVE. - 10. Set the PLATFORM_CTRL register to enable multichip mode and CHIPID=1. For this, uncomment - the SOCCON with offset 0x1170 and set the value 0x00000101. Save and close the file. Run - sync command in case of Linux host. - The line should now read: **SOCCON: 0x1170 0x00000101 ; SoC SCC PLATFORM_CTRL** - -Booting the Setup ------------------ - 1. Copy all the firmware binaries to SOFTWARE folder in both master and slave board's micro SD - card. Run sync command in case of Linux host. Note that uefi.bin file is not required to be - copied to slave micro SD card as UEFI will be run only in the master chip. - For getting the sources and building the binaries please refer to `user-guide`_ - 2. Shutdown both the boards. - 3. Reboot the slave board first and let it boot. Then reboot the master board. This is done - because the SCP firmware running in master board expects the slave board to respond to the - I2C command when it boots. If the slave board is not responding for the I2C command then - master assumes that it is running in single chip environment and continues to boot in single - chip mode. This is explicitly done to avoid any delays in waiting for slave to respond that - will affect single chip environment where there is no slave connected at all. - 4. If master SCP finds a slave connected and responding then master SCP will perform several - handshakes with slave SCP to bring-up the CCIX link and boot the slave chip's cores. - -After Booting -------------- - 1. UEFI's Dynamic ACPI framework exposes both master and slave chip's processors and memories to - Linux. Assuming 16GB DDR memory connected each on master and slave boards, Linux will see - 8 cores (4 cores in master chip + 4 cores in slave chip) and 32GB DDR memory space. - 2. Once Linux has booted, /proc/cpuinfo and /proc/meminfo can be dumped to see the total core - and memory information that Linux currently sees. - 3. Also the slave board resources (slave CPUs and slave DDR memory) is treated as separate NUMA - node in Linux which can be seen using the numactl --hardware command. - -Limitations ------------ - 1. Though the multichip high speed connection is made using CCIX enabled PCIe controllers which - supports GEN4 speed, only GEN3 speed has been validated for multichip operation. This affects - the cross-chip memory access latency. - 2. The timer synchronization internal logic doesn't accounted for the external sync signals pad - timings. So the PIK clock for timer synchronization module has to be reduced to 150MHz from - actual 800MHz. - 3. The REFCLK counter values on both master and slave chips has to be reset before starting the - synchronization process. - 4. Timer synchronization interrupt flag has no information on the source of interrupt. So - synchronization is retriggered everytime an interrupt was hit. - -References ----------- -- http://infocenter.arm.com/help/topic/com.arm.doc.101489_0000_01_en/arm_neoverse_n1_system_development_platform_technical_reference_manual_101489_0000_01_en.pdf -- https://www.ccixconsortium.com/ccix-library/ - ----------- - -*Copyright (c) 2020, Arm Limited. All rights reserved.* - -.. _user-guide: ../user-guide.rst diff --git a/docs/n1sdp/pcie-sr-iov.rst b/docs/n1sdp/pcie-sr-iov.rst deleted file mode 100755 index c3c5135..0000000 --- a/docs/n1sdp/pcie-sr-iov.rst +++ /dev/null @@ -1,54 +0,0 @@ -PCIe SR-IOV on Neoverse N1 SDP -============================== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Introduction ------------- -The Neoverse N1 System Development Platform (N1SDP) supports two PCIe root ports each -supporting the standard PCIe features including the Single Root I/O Virtualization (SR-IOV) -feature. This document gives an overview of how to enable and test the SR-IOV feature on -N1SDP. - -Note: -Due to the PCIe limitations in N1SDP platform (`pcie-support`_), the SR-IOV feature has not been completely validated. - -Pre-Requisite -------------- - 1. Latest software stack synced by following steps given in `user-guide`_ - 2. Ensure that the Linux tree in the synced workspace contains the SR-IOV and PCI ACS override patches. This should have been already applied when syncing the code. - -Steps to verify SR-IOV ----------------------- - 1. Add kernel config CONFIG_IXGBEVF=y to linux/arch/arm64/configs/defconfig file. This is required to enable drivers for the mentioned Intel card. - 2. Build the software stack and flash the Ubuntu image onto the boot device. Do initial boot of the board which installs Ubuntu and perform second boot which boots Ubuntu kernel. - 3. Login to target Ubuntu console and edit the file /etc/default/grub. Add pcie_acs_override=id:13b5:0100 option to the GRUB_CMDLINE_LINUX_DEFAULT. Save this file and run update-grub command. - 4. Reboot the board from Ubuntu console using reboot now command. - 5. Now Linux probes and assigns separate IOMMU groups for all PCIe devices. - 6. Virtual functions can be enabled from sysfs using following command: - - *echo 63 > /sys/bus/pci/devices/0001\:01\:00.0/sriov_numvfs* - - Note that in test environment the Intel card's ethernet port 0 is identified in Segment:1 Bus:1 Dev:0 Function:0 - -Limitations ------------ - 1. SR-IOV feature is only supported in CCIX slot and not in the PCIe slots. This is due to the - on-board PCIe switch not supporting the ARI capability to which the PCIe slots are connected. - 2. Only Intel X540-T2 card has been validated for the SR-IOV feature. - -References ----------- -- http://infocenter.arm.com/help/topic/com.arm.doc.101489_0000_01_en/arm_neoverse_n1_system_development_platform_technical_reference_manual_101489_0000_01_en.pdf - ----------- - -*Copyright (c) 2020, Arm Limited. All rights reserved.* - -.. _user-guide: ../user-guide.rst -.. _run-on-n1sdp: run-on-n1sdp.rst -.. _pcie-support: pcie-support.rst diff --git a/docs/n1sdp/pcie-support.rst b/docs/n1sdp/pcie-support.rst deleted file mode 100644 index bffa7e5..0000000 --- a/docs/n1sdp/pcie-support.rst +++ /dev/null @@ -1,70 +0,0 @@ -PCIe support on Neoverse N1 SDP -=============================== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Support for PCIe in Arm's Neoverse N1 SDP software releases ------------------------------------------------------------ -The supplied Neoverse software stack includes support for PCIe. However there are -two issues (detailed below) with the PCIe root port hardware IP present on -Neoverse N1 SDP. These impact generic code in EDK II UEFI and Linux. - -Arm is maintaining patches and implementing workarounds in the following Linaro -git repository: http://git.linaro.org/landing-teams/working/arm/n1sdp-pcie-quirk.git/ -The patches will be regularly rebased so that they apply cleanly to the relevant -components (SCP-firmware, mainline Linux, and upstream EDK II UEFI). -The git repository also provides a shell script, patch_apply.sh. - -The patches are applied automatically as part of the Arm reference platform software -workspace sync process, providing a software stack with full PCIe support. However, note that -it is not possible to use an unmodified Linux distribution release on Neoverse N1SDP, -without patching and rebuilding the kernel shipped with that distribution. - - -SLVERR on PCIe device and function enumeration --------------------------------------------------- -Linux and EDK II UEFI use standardised PCIe enumeration code based -on the assumption that PCIe compliant root ports must return magic number 0xFFFFFFFF -when either a device is not connected or a function is not implemented. -The PCIe root port hardware IP on Neoverse N1 SDP boards instead asserts -an AXI SLVERR response, triggering a bus fault on the applications processor -performing PCIe enumeration. - -A software workaround has been implemented in the System Control Processor (SCP) -that performs minimal PCIe enumeration and generates a bus/device/function (BDF) -table that it places in shared Non-secure SRAM. During this minimal enumeration, -the SCP ignores any bus faults from accessing PCIe configuration space, -effectively suppressing the non-compliant AXI SLVERR responses generated by the -PCIe root port hardware IP. Patches have also been applied to EDK II UEFI and Linux -to use the generated BDF table during their own PCIe enumeration routines. - -Non-contiguous configuration space ----------------------------------- -Linux and EDK II UEFI use standardised PCIe enumeration code based on the assumption -that the PCIe Enhanced Configuration Access Mechanism (ECAM) base address is the same -as the base address of the root port's configuration space. These assumptions are not -valid for N1SDP leading to issues identifying the root port during PCIe enumeration. - -A software workaround has been added to the SCP that inserts the base address of the -PCIe root port's configuration space as the first word in the BDF table in shared -Non-secure SRAM in both EDK II UEFI and Linux. The generic PCIe code has been patched to -read the base address of the PCIe root port configuration space from the BDF table; -this base address is then automatically used whenever a given BDF is all zeroes. - -PCIE Root Port config space supports only 32 bits R/W ------------------------------------------------------ - -The root port configuration space supports only 32-bit accesses. However, standard UEFI and Linux -drivers may perform 8-bit and 16-bit read/write to this space which will end up in erroneous result. -To avoid this, software workarounds has been added to convert the 8-bit/16-bit access to 32-bit access -using read-modify-write method. - - --------------- - -*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* - diff --git a/docs/n1sdp/release-notes.rst b/docs/n1sdp/release-notes.rst deleted file mode 100755 index bd40de1..0000000 --- a/docs/n1sdp/release-notes.rst +++ /dev/null @@ -1,77 +0,0 @@ -Release Notes -============= - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Features and Fixes ------------------- -The following is a summary of the key software features of the tagged N1SDP-2020.07.27 release. - -- Stability improvement over the GEN4 x16 link on CCIX slot. Verified with Mellanox Card (MCX516A-CDAT). -- Switched to user space dhcp client from the kernel space dhcp client for the initial ubuntu boot. -- Updated MCC firmware (mbb_v107) – This prompt for the recommended PMIC firmware. -- Added new PMIC firmware (300k_8c2) – This supports for boards manufactured post Nov 2019. -- Added latest PCC firmware (pcc_v050) – This allows to update of older boards. - -Precautions ------------ -- The system thermal monitoring and control features are not yet calibrated, - therefore do not operate the unit above room temperature (approximately 25°C): - -- The N1SDP is intended for use within a laboratory or engineering development - environment. Do not use the N1SDP near equipment that is sensitive to - electromagnetic emissions, for example, medical equipment. - -- Never subject the board to high electrostatic potentials. - Observe Electrostatic Discharge (ESD) precautions when handling any board. - - - Always wear a grounding strap when handling the board. - - Avoid touching the component pins or any other metallic elements. - -- Update/Change board firmware only if MCC FW ask to do so, - see here for more information - https://community.arm.com/developer/tools-software/oss-platforms/w/docs/604/notice-potential-damage-to-n1sdp-boards-if-using-latest-firmware-release - -- Note: The case front panel USB 3.0 ports and & audio jacks are NOT connected/usable. - They will be removed on later versions. - -PCIe Testing ------------- -Limited PCIe testing done on: -- Mellanox ConnectX-5 -- Xilinx U280 CCIX card - -Known Issues or limitations ---------------------------- -- If either of the two boards needs to boot-up in a single chip mode with a C2C setup, - then the other board should be powered off. -- To boot a standard distribution on N1SDP platform the kernel must be patched - with the PCIe quirks. See the article `PCIE`_ -- PCIe root port is limited to GEN3 speed due to the on-board PCIe switch supporting maximum GEN3 speed. -- GEN4 x16 link in CCIX slot has not been performance tested. -- CCIX usecases (Accelerator/Multichip) is limited to GEN3 speed. -- Page Request Interface (PRI) feature is not available in both SMMUs interfaced with PCIe & CCIX root ports. -- Currently only Micron 8GB single Rank DIMM (part number: MTA9ASF1G72PZ-2G6D1) and - 16GB dual Rank DIMMs (part number:MTA18ASF2G72PDZ-2G6E1) are supported. -- Multichip usecase does not enable peripheral access in the slave chip. -- Stability issues have been observed on long stress tests of the system. -- On-board HDMI connection is not supported for graphics output. PCIe graphics card can be used for graphics support. - -Disclaimer ------------- -- Limited Testing for now due to current global scenario, to be revisited once we get back on site. - -Support -------- -For support email: support-subsystem-enterprise@arm.com - --------------- - -*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* - - -.. _PCIE: pcie-support.rst diff --git a/docs/n1sdp/run-on-n1sdp.rst b/docs/n1sdp/run-on-n1sdp.rst deleted file mode 100755 index 6534cb7..0000000 --- a/docs/n1sdp/run-on-n1sdp.rst +++ /dev/null @@ -1,172 +0,0 @@ -Running the software on N1SDP -============================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Introduction ------------- - -The Neoverse N1 System Development Platform (N1SDP) is an enterprise class reference board based on the Neoverse N1 core. -This document is a guide on how to run an Arm Reference Platforms software stack on N1SDP . - -These instructions assumes you have already followed the `user-guide`_ to sync and build an Arm Reference Platforms -software stack for N1SDP. - -The synced workspace includes several board files and prebuilt binaries under the *<workspace/board_firmware/>* directory. - -Setup Preparation ------------------ - -**Preparing a bootable disk** - -A bootable disk (USB stick or SATA drive) can be prepared by formatting it with the prebuilt image located at -*<workspace/grub-ubuntu.img>* or the source build image at the location *<workspace/output/n1sdp/build_artifact/grub-ubuntu.img>* -after the source build. - -This is a bootable GRUB image comprising LINUX and an Ubuntu 18.04 file system. The partitioning and packaging is performed -during the build. - -Use the following commands to burn the GRUB image to a USB stick or SATA drive: - - :: - - $ lsblk - $ sudo dd if=grub-ubuntu.img of=/dev/sdX bs=1M - $ sync - -Note: Replace ``/dev/sdX`` with the handle corresponding to your USB stick or SATA drive, as identified by the ``lsblk`` command. - -Connect the bootable media to the N1SDP platform; USB sticks should be inserted into to one of the four USB3.0 ports, while -SATA drives should be connected to one of the two SATA ports. - - -**Configure COM Ports** - -Connect a USB-B cable between your host PC and N1SDP's DBG USB port, then power ON the board. The DBG USB connection will enumerate -as four virtual COM ports assigned to the following processing entities, in order - - :: - - COM<n> - Motherboard Configuration Controller (MCC) - COM<n+1> - Application Processor (AP) - COM<n+2> - System Control Processor (SCP) - COM<n+3> - Manageability Control Processor (MCP) - -Please check Device Manager in Windows or ls /dev/ttyUSB* in Linux to identify <n>. - -Use a serial port application such as *PuTTy* or *minicom* to connect to all virtual COM ports with the following settings: - - :: - - 115200 baud - 8-bit word length - No parity - 1 stop bit - No flow control - -Note: Some serial port applications refer to this as "115200 8N1" or similar. - -Running the deliverables on N1SDP ---------------------------------- - -Ensure both BOOT CONF switches are in the OFF position, then issue the following -command in the MCC console: - - Cmd> USB_ON - -This will mount the on-board microSD card as a USB Mass Storage Device on the -host PC with the name N1SDP; how you then proceed will depend on whether you -built from source or chose a prebuilt configuration. - -Ensure that time is correctly set on N1SDP board through following command in -the MCC console if not set then change it accordingly: - - :: - - Cmd> debug - Debug> time - Debug> date - Debug> exit - - - - -**Prebuilt configuration** - -Copy the contents of -<workspace/n1sdp-board-firmware-${RELEASE_TAG}/n1sdp-board-firmware-${RELEASE_TAG}/ -onto the mounted microSD card, then skip to the ** Booting the board ** -section. - - -**Built from source** - -Copy the contents of <workspace/board_firmware/> onto the mounted microSD card, -then copy the .bin files mcp_fw.bin, mcp_rom.bin, scp_fw.bin, and scp_rom.bin from <workspace/output/n1sdp/build_artifact/> to the -<SOFTWARE/> directory on the mounted microSD card, overwriting the existing files. - -**Booting the board** - -Insert the bootable disk created earlier, and connect an ethernet cable to the -Gigabit Ethernet port to avoid DHCP timeouts during boot. - -Shutdown and reboot the board by issuing the following commands to the MCC -console: - - :: - - Cmd> SHUTDOWN - Cmd> REBOOT - -On rebooting, the board will copy the new binaries and firmware images from -the microSD card into either on-board QSPI flash or DDR3 memory via the IOFPGA; -see <MB/images.txt> on the microSD card. - -Enter the UEFI menu by pressing Esc on the AP console as the edk2 logs start -appearing; from here, enter the UEFI Boot Manager menu and then select media -having Ubuntu 18.04 bootable image. -Ubuntu 18.04 will boot in two stages, onces first boot is finished reboot the board -from MCC console. - - :: - - Cmd> REBOOT - -The system will boot into a minimal Ubuntu 18.04 environment. -Login as root and install any required packages from the console -# apt-get install <package-name> - -Building Kernel Modules Natively --------------------------------- -Native building of kernel modules typically require kernel headers to be installed on the platform. -However, a bug in deb-pkg packs the host executables rather than the target executables. This can be -worked around by building and installing the kernel natively on the platform. - - 1. Boot the N1SDP board with Ubuntu filesystem and login as root. - 2. Install build packages using following command: - apt-get install -y git build-essential bc bison flex libssl-dev - 3. git clone -b n1sdp http://git.linaro.org/landing-teams/working/arm/kernel-release.git - 4. git clone http://git.linaro.org/landing-teams/working/arm/n1sdp-pcie-quirk.git - 5. cd kernel-release/ - 6. git am ../n1sdp-pcie-quirk/linux/\*.patch - 7. mkdir out - 8. cp -v /boot/config-5.4.0+ out/.config - 9. make O=out -j4 - 10. make O=out modules_install - 11. make O=out install - 12. update-grub - 13. sync - 14. Reboot the board and when Grub menu appears, select the Advanced Boot Options -> 5.4.0 kernel - for booting. - --------------- - -*Copyright (c) 2020, Arm Limited. All rights reserved.* - -.. _user-guide: ../user-guide.rst - diff --git a/docs/n1sdp/user-guide.rst b/docs/n1sdp/user-guide.rst new file mode 100644 index 0000000..a8581d0 --- /dev/null +++ b/docs/n1sdp/user-guide.rst @@ -0,0 +1,2 @@ +The N1Sdp documentation has been migrated to +https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/tree/master/docs/n1sdp diff --git a/docs/rddaniel/how-to/busybox-boot.rst b/docs/rddaniel/how-to/busybox-boot.rst deleted file mode 100644 index ccf4096..0000000 --- a/docs/rddaniel/how-to/busybox-boot.rst +++ /dev/null @@ -1,152 +0,0 @@ -How to build RD-Daniel and RD-Daniel-XLR platform software to validate busybox boot -=================================================================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - -Busybox boot on RD-Daniel and RD-Daniel-XLR platforms ------------------------------------------------------ - -Busybox is a lightweight executable which packages lots of POSIX compliant UNIX -utilities in a single file system. The busybox boot test on RD-Daniel and -RD-Daniel-XLR platforms ensures that the software stack which runs on the model -is able to boot a Linux operating system with a busybox filesystem. - -Boot test is especially helpful when porting the software stack for new -platforms which are derivative of the RD-Daniel or RD-Daniel-XLR platform as -this test can be quickly executed to ensure that the various software components -are properly integrated and verify the basic functionality of various software -components. As part of this test, the following components of the software stack -are built - *TF-A*, *UEFI*, *Linux*, *GRUB*, *SCP*. - -This document describes how to build and execute the boot test on the -*RD-Daniel* and *RD-Daniel-XLR* fastmodel. - -Procedure to build Busybox boot test for RD-Daniel and RD-Daniel-XLR platform ------------------------------------------------------------------------------ - -This section describes how to build the disk image for busybox boot test. The -disk image consists of an EFI partition which has grub and an ext3 partition -which has the linux kernel image. Examples on how to use the build command for -busybox boot test are listed below. - -To build the software stack, the command to be used is - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p <platform> <command> - -Supported command line options are listed below - - - <platform> - - - Supported platforms are - - - ``rddaniel`` for RD-Daniel - - ``rddanielxlr`` for RD-Daniel-XLR - - - <command> - - - Supported commands are - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p rddaniel all - - - This command cleans, builds and packages the software stack needed - for the busybox boot test on RD-Daniel platform. - - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p rddanielxlr build - - - This command performs an incremental build of the software components - included in the software stack for the RD-Daniel-XLR platform. Note: - this command should be followed by the 'package' command to complete the - preparation of the FIP and the disk image. - - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p rddaniel package - - - This command packages the previously built software stack and prepares - the FIP and the disk image. - -Procedure for validating Busybox boot test for RD-Daniel and RD-Daniel-XLR platforms ------------------------------------------------------------------------------------- - -After the build for busybox boot test is complete, the following command starts -the execution of the *RD-Daniel* or *RD-Daniel-XLR* fastmodel and the software -boots up to the busybox prompt. Examples on how to use the command are listed -below. - -To boot up to the busybox prompt, the command to be used is - - :: - - cd model-scripts/rdinfra - ./boot.sh -p <platform> -a <additional_params> -n [true|false] - - -Supported command line options are listed below - - - -p <platform> - - - Specifies the platform to build. Supported platforms are - - - ``rddaniel`` for RD-Daniel - - ``rddanielxlr`` for RD-Daniel-XLR - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the Boot test are as listed below. - - - :: - - ./boot.sh -p rddanielxlr - - - This command starts the execution of the RD-Daniel-XLR model and the - software boots up to the Busybox prompt. - - - :: - - ./boot.sh -p rddaniel -n true - - - This command starts the execution of the RD-Daniel model and the - software boots up to the Busybox prompt. The model supports - networking allowing the software running within the model to access - the network. - - - :: - - ./boot.sh -p rddaniel -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the RD-Daniel model with - networking enabled and the software boots up to the Busybox prompt. - Additional parameters to the model are supplied using the -a command - line parameter. - --------------- - -*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* diff --git a/docs/rddaniel/how-to/create-tap-interface.rst b/docs/rddaniel/how-to/create-tap-interface.rst deleted file mode 100644 index a6c7d45..0000000 --- a/docs/rddaniel/how-to/create-tap-interface.rst +++ /dev/null @@ -1,59 +0,0 @@ -How to create tap interface to enable networking for FVPs -========================================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Context -------- - -RD-Daniel fast model supports virtual networking and it can interface with the -host PC network through the tap interface setup on the host machine. The steps -to setup a TAP interface on the host PC are listed below. This requires Ubuntu -16.04 or Ubuntu 18.04 as the host PC. - - -How to setup tap interface --------------------------- - -- Install the ``bridge-utils`` package - - :: - - sudo apt-get install bridge-utils - -- The first step is to create a bridge and add the host PC network as its - interface. Here, ``br0`` is the bridge name and ``enp0s3`` is the host PC - network device name. Replace these names with the names of the interfaces - used on the host PC. - - :: - - sudo brctl addbr br0 - sudo brctl addif br0 enp0s3 - sudo ifconfig enp0s3 0.0.0.0 - sudo ifconfig br0 up - sudo dhclient br0 - -- Next setup is to add the tap interface. Here, ``tap0`` is the name of the tap - interface. - - :: - - sudo ip tuntap add dev tap0 mode tap user $(whoami) - sudo ifconfig tap0 0.0.0.0 promisc up - sudo brctl addif br0 tap0 - -Note: These steps do not make a persistent instance of the bridge and the tap -interface. After the host PC reboots, these steps have to be repeated again. - -Refer `this documentation <https://wiki.linuxfoundation.org/networking/bridge>`_ -for more details. - --------------- - -*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* diff --git a/docs/rddaniel/how-to/distro-test.rst b/docs/rddaniel/how-to/distro-test.rst deleted file mode 100644 index 222c2b3..0000000 --- a/docs/rddaniel/how-to/distro-test.rst +++ /dev/null @@ -1,217 +0,0 @@ -How to install and boot a linux distribution -============================================ - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Linux distribution boot support --------------------------------- -RD-Daniel software stack supports the installation and boot of various linux -distributions such as Debian, Fedora or Ubuntu. The distribution is installed -on a SATA disk and the installed image can be used for multiple boots. - - -Procedure to build RD-Daniel software stack for distro boot ------------------------------------------------------------ - -The RD-Daniel platform software stack has to be first built to prepare for the -distribution installation step. The procedure to build the RD-Daniel platform -software stack is listed below. - -To build the RD-Daniel software stack, the command to be used is - - - :: - - ./build-scripts/build-test-uefi.sh -p <platform> <command> - -Supported command line options are listed below - - - <platform> - - - Supported platforms are - - - ``rddaniel`` for RD-Daniel - - ``rddanielxlr`` for RD-Daniel-XLR - - - <command> - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/build-test-uefi.sh -p rddaniel all - - - This command cleans, builds and packages the RD-Daniel Config-M software - stack needed for the distro installation/boot test for the RD-Daniel - Config-M platform. - - - :: - - ./build-scripts/build-test-uefi.sh -p rddanielxlr build - - - This command performs an incremental build of the software components - included in the software stack for the RD-Daniel Config-XLR platform. - Note: this command should be followed by the ``package`` command to - complete the preparation of the fip image. - - - :: - - ./build-scripts/build-test-uefi.sh -p rddanielxlr package - - - This command packages the previously built software stack and prepares - the fip image. - - -Procedure for installing a distro on RD-Daniel platform -------------------------------------------------------- - -After the build for the distro is complete, a distribution can be installed into -a SATA disk image. Before beginning the installation process, download the CD -iso image of the required distribution version. - -The command used to begin the distro installation is: - - :: - - cd model-scripts/rdinfra - ./distro.sh -p <platform> -i <iso_image_path> -s <disk size> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -p <platform> - - - Specifies the platform to build. Supported platforms are - - - ``rddaniel`` for RD-Daniel - - ``rddanielxlr`` for RD-Daniel-XLR - - - -i </path/to/iso_image_path> - - - Absolute path to the downloaded distribution installer iso image. - - - -s <disk_size> - - - Size of the SATA disk image (in GB) to be created. 16GB and above is - good enough for most use cases. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -An example of the command to begin the boot of the debian distribution is -listed below. - - - :: - - ./distro.sh -p rddaniel -i /path/to/debian-10.6.0-arm64-xfce-CD-1.iso -s 16 - - - This command creates a 16GB SATA disk image, boot the RD-Daniel Config-M - software stack and start the installation of debian distro. - - - From here on, follow the instructions of the choosen distribution installer. - For more information about the installation procedure, refer online - installation manuals of the choose distribution. - - - After the installation is completed, the disk image with a random name - "<number>.satadisk" will be created in model-scripts/rdinfra/ folder. - User should use this disk image when booting the Debian distribution. - -Additional distribution specific instructions (if any) - - - Debian Distribution installation - - - During installation, the installer will prompt the user with the message - 'Load CD-ROM drivers from removable media' and display two options - - Yes/No. - - - Select the option 'No' which would again display two options - - Yes/No. - - Select the option 'Yes' which will display 'Automatic detection - did not find CD-ROM'. - - Module needed for accessing CD-ROM and display two options - - - none - - cdrom - - - Select the option 'none' and enter ``/dev/vda``. The installation - media on the virtio disk will be detected and installation - continues. - - -Procedure for booting distro on RD-Daniel platform --------------------------------------------------- - -To boot the installed distro, use the following command: - - :: - - cd model-scripts/rdinfra - ./distro.sh -p <platform> -d <satadisk_path> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -p <platform> - - - Specifies the platform to build. Supported platforms are - - - ``rddaniel`` for RD-Daniel - - ``rddanielxlr`` for RD-Daniel-XLR - - - -d <satadisk_path> - - - Path to the installed SATA disk image created using the previous - section. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example command functionality are as listed below. - - - :: - - ./distro.sh -p rddaniel - - - This command looks for the available .satadisk image in the - ``model-scripts/rdinfra`` folder and boots with that image. If multiple - .satadisk images are found, it will list them all but won't boot. - - - :: - - ./distro.sh -p rddaniel -d ./fedora.satadisk - - - This command begins the distro boot from the ``fedora.satadisk`` image. - - -This completes the validation of the linux distribution installation and boot -functionalities. - --------------- - -*Copyright (c) 2020, Arm Limited. All rights reserved.* diff --git a/docs/rddaniel/how-to/winpe-test.rst b/docs/rddaniel/how-to/winpe-test.rst deleted file mode 100644 index 888f9cc..0000000 --- a/docs/rddaniel/how-to/winpe-test.rst +++ /dev/null @@ -1,128 +0,0 @@ -How to boot WinPE -================= - -.. section-numbering:: - :suffix: . - -.. contents:: - - -WinPE boot support ------------------- -RD-Daniel software stack supports the boot of Windows Preinstallation -Environment (WinPE). A pre-built WinPE disk image is provided as a SATA disk to -RD-Daniel FVP which then is used to boot WinPE. - - -Procedure to build RD-Daniel software stack for WinPE boot ----------------------------------------------------------- - -The RD-Daniel platform software stack has to be first built to prepare for the -WinPE boot. The procedure to build the RD-Daniel platform stack is listed below. - -To build the RD-Daniel software stack, the command to be used is - - - :: - - ./build-scripts/build-test-uefi.sh -p <platform> <command> - -Supported command line options are listed below - - - <platform> - - - Supported platforms are - - - ``rddaniel`` for RD-Daniel - - ``rddanielxlr`` for RD-Daniel-XLR - - - <command> - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/build-test-uefi.sh -p rddaniel all - - - This command cleans, builds and packages the RD-Daniel Config-M software - stack needed for the WinPE boot for the RD-Daniel Config-M platform. - - - :: - - ./build-scripts/build-test-uefi.sh -p rddanielxlr build - - - This command performs an incremental build of the software components - included in the software stack for the RD-Daniel Config-XLR platform. - Note: this command should be followed by the ``package`` command to - complete the preparation of the fip image. - - - :: - - ./build-scripts/build-test-uefi.sh -p rddanielxlr package - - - This command packages the previously built software stack and prepares - the fip image. - - -Procedure for preparing a WinPE disk image ------------------------------------------- - -To prepare a WinPE disk image, follow the instructions listed on this page - -`Boot to WinPE <https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/download-winpe--windows-pe/>`_ - -Procedure for booting WinPE on RD-Daniel platform -------------------------------------------------- - -To boot from the WinPE disk image, use the following command: - - :: - - cd model-scripts/rdinfra - ./distro.sh -p <platform> -d <satadisk_path> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -p <platform> - - - Specifies the platform to build. Supported platforms are - - - ``rddaniel`` for RD-Daniel - - ``rddanielxlr`` for RD-Daniel-XLR - - - -d <satadisk_path> - - - Absolute path to the WinPE disk image created using the previous section. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example command functionality are as listed below. - - - :: - - ./distro.sh -p rddaniel -d /path/to/WinPE_arm64.iso - - - This command begins the WinPE boot from the ``WinPE_arm64.iso`` image. - Follow the instructions on console to complete the WinPE boot. - - -This completes the validation of WinPE boot on RD-Daniel platform. - --------------- - -*Copyright (c) 2020, Arm Limited. All rights reserved.* diff --git a/docs/rddaniel/user-guide.rst b/docs/rddaniel/user-guide.rst index c998f92..0dbce3d 100644 --- a/docs/rddaniel/user-guide.rst +++ b/docs/rddaniel/user-guide.rst @@ -1,237 +1,2 @@ -RD-Daniel platform user guide -============================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Introduction ------------- - -RD (Reference Design) is a collection of resources to provide a representative -view of typical compute subsystems that can be designed and implemented using -specific generations of Arm IP. - -RD-Daniel supports the following configurations and those include the following -ARM IP's: - - - ARM CPU: - - - RD-Daniel Config M: - - 16xMP1 Zeus CPUs - - - RD-Daniel Config L: - - 32xMP1 Zeus CPUs - - - RD-Daniel Config XL: - - 128xMP1 Zeus CPUs - - - CMN-Rhodes (with CAL): 16MB System Level Cache and 32MB Snoop Filter - - Multiple AXI expansion ports for I/O Coherent PCIe, Ethernet, offload - - Arm Cortex-M7 for System Control Processor (SCP) and - Manageability Control Processor (MCP) - -RD-Daniel Config XL is a quad-chip configuration of Config L in which four -RD-Daniel Config L platforms are connected through high speed CCIX link. The -CCIX link is enabled through CMN-Rhodes's Coherent Multichip Link (CML) feature. - -The Fixed Virtual Platform of RD-Daniel Config XL supports 4xMP1 Zeus CPUs on -each chips totalling to 16xMP1 Zeus CPUs. The FVP version of RD-Daniel Config XL -is referred as RD-Daniel-XLR in this document. - -This document is a user guide on how to setup, build and run the software stack -of RD-Daniel and RD-Daniel-XLR on Fixed Virtual Platform. - - -Host machine requirements -------------------------- - -The minimum recommended host PC specification for building the software stack -and running the RD-Daniel FVP model is a dual-core processor running at 2GHz -with 8GB of RAM. For best performance, use a machine with a quad-core processor -running at 2.6GHz with 16GB of RAM with free hard disk space of at least 64GB. -For running RD-Daniel-XLR FVP model, user need host PC with atleast 64GB of RAM -and 128GB of hard disk space. - -The software package has been tested on **Ubuntu 16.04 LTS (64-bit)** and -**Ubuntu 18.04 LTS (64-bit)**. This guide assumes that the user is on either of -this operating system. - - -Repo tool setup ---------------- - -The software stack for RD-Daniel and RD-Daniel-XLR is available in multiple git -repositories. In order to simplify downloading the software stack, `repo tool <https://source.android.com/setup/develop/repo>`_ -can be used. This section explains how to setup git and repo tool. - -- Install Git by using the following command - - :: - - sudo apt-get install git - -- Git installation can be confirmed by checking the version - - :: - - git --version - - This should return the git version in a format such as ``git version 2.7.4`` - -- Set name and email address in git - - :: - - git config --global user.name "<your-name>" - git config --global user.email "<your-email@example.com>" - -- Download the repo tool - - :: - - sudo apt-get install repo - -This completes the setup of the repo tool. - - -Syncing the software stack --------------------------- - -The manifest file, which contains the location of all the git repositories of -RD-Daniel and RD-Daniel-XLR software stack, is available `here <https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git/>`_. -This section explains how to sync the software stack. - -- Switch to a new folder - - :: - - mkdir rd-daniel - cd rd-daniel - -- For obtaining the latest *stable* software stack, use the following commands - to sync: - - :: - - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m pinned-rddaniel.xml -b refs/tags/<RELEASE_TAG> - repo sync -j $(nproc) --fetch-submodules --force-sync - - - Note: The RELEASE_TAG can be found in the `Release Tags`_ section or from the - release notes, if obtained. To obtain the most recent software stack (but - not fully validated), use "master" as the branch to checkout and pass it as - the value to the "-b" parameter as shown in the commands below. - - :: - - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m pinned-rddaniel.xml -b master - repo sync -j $(nproc) --fetch-submodules --force-sync - - -This will download the RD-Daniel software stack into the ``rd-daniel`` folder. - - -Installing prerequisites ------------------------- - -Run the following command to install all the required prerequisites to build the -software stack: - - :: - - sudo ./build-scripts/rdinfra/install_prerequisites.sh - -It is mandatory to execute this script at least once before build and executing -the software stack. - - -Downloading the GCC toolchain binaries --------------------------------------- - -In addition to the prerequisites installed, gcc toolchain binaries have to be -downloaded and placed at the ``tools/gcc`` folder. Use the following commands -to download and untar the binaries: - - :: - - # Move to the rd-daniel software stack directory - cd rd-daniel - - # Create a folder for gcc under tools folder - mkdir -p tools/gcc - cd tools/gcc - - # Download and extract the binaries - wget https://developer.arm.com/-/media/Files/downloads/gnu-a/8.3-2019.03/binrel/gcc-arm-8.3-2019.03-x86_64-arm-eabi.tar.xz - wget https://developer.arm.com/-/media/Files/downloads/gnu-a/8.3-2019.03/binrel/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz - - tar -xJf gcc-arm-8.3-2019.03-x86_64-arm-eabi.tar.xz - tar -xJf gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz - -This completes the setup of the GCC toolchain binaries. - - -Obtaining the RD-Daniel and RD-Daniel-XLR Fast Model ----------------------------------------------------- - -User can request for the latest version of RD-Daniel and RD-Daniel-XLR Fast -Model by sending a email to Arm at this email address: `support-connect@arm.com <mailto:support-connect@arm.com>`_. - -Follow the instruction in the installer and setup the FVP. Typically, the -installer will ask to create a new folder in the home directory. You can either -install the FVP in the home folder, or in the ``fastmodel/refinfra`` folder -inside the ``rd-daniel`` folder. If you would like to install in the -``fastmodel/refinfra`` folder, when asked for the install location, -provide the absolute path of the ``fastmodel/refinfra``. - -Before launching any scripts from ``model-scripts`` folder, export the absolute -path of the model as an environment variable. - - :: - - export MODEL=<absolute-path-of-the-model-executable> - -This completes the steps to obtain the RD-Daniel and RD-Daniel-XLR Fast Model. - - -Supported Features ------------------- - -RD-Daniel and RD-Daniel-XLR software stack supports the following features. - -- busybox boot (`Busybox`_). -- distro boot (`Distro`_). -- winpe boot (`WinPE`_). - - -Release Tags ------------- - -Here's the list of release tags and corresponding Fast Model version supported: - -+-----------------------+-------------------------+----------------------------+ -| Release Tag | RD-Daniel FVP Version | RD-Daniel-XLR FVP Version | -+=======================+=========================+============================+ -| RD-INFRA-2020.11.09 | 11.12.58 | 11.12.58 | -+-----------------------+-------------------------+----------------------------+ -| RD-INFRA-2020.04.16 | 11.10.36 | 11.10.36 | -+-----------------------+-------------------------+----------------------------+ -| | | | -+-----------------------+-------------------------+----------------------------+ -| | | | -+-----------------------+-------------------------+----------------------------+ -| | | | -+-----------------------+-------------------------+----------------------------+ - --------------- - -*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* - - -.. _Busybox: how-to/busybox-boot.rst -.. _Distro: how-to/distro-test.rst -.. _WinPE: how-to/winpe-test.rst +RD-Daniel (aka RD-V1) platform documentation has been migrated to +https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/tree/master/docs/infra diff --git a/docs/rde1edge/how-to/busybox-boot.rst b/docs/rde1edge/how-to/busybox-boot.rst deleted file mode 100644 index da538ac..0000000 --- a/docs/rde1edge/how-to/busybox-boot.rst +++ /dev/null @@ -1,137 +0,0 @@ -How to build RD-E1-Edge platform software to validate busybox boot -================================================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - -Busybox boot on RD-E1-Edge platform ------------------------------------ - -Busybox is a lightweight executable which packages lots of POSIX compliant UNIX -utilities in a single file system. The busybox boot test on RD-E1-Edge platform -ensures that the RD-E1-Edge software stack which runs on the model is able to -boot a Linux operating system with a busybox filesystem. - -Boot test is especially helpful when porting the software stack for new -platforms which are derivative of the RD-E1-Edge platform as this test can be -quickly executed to ensure that the various software components are properly -integrated and verify the basic functionality of various software components. -As part of this test, the following components of the software stack are built - -*TF-A*, *UEFI*, *Linux*, *GRUB*, *SCP*. - -This document describes how to build and execute the boot test on the -*RD-E1-Edge* fastmodel. - -Procedure to build Busybox boot test for RD-E1-Edge platform ------------------------------------------------------------- - -This section describes how to build the disk image for busybox boot test. The -disk image consists of an EFI partition which has grub and an ext3 partition -which has the linux kernel image. Examples on how to use the build command for -boot test are listed below. - -To build the software stack, the command to be used is - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p rde1edge <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p rde1edge all - - - This command cleans, builds and packages the software stack needed - for the busybox boot test on RD-E1-Edge platform. - - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p rde1edge build - - - This command performs an incremental build of the software components - included in the software stack for the RD-E1-Edge platform. Note: this - command should be followed by the 'package' command to complete the - preparation of the FIP and the disk image. - - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p rde1edge package - - - This command packages the previously built software stack and prepares - the FIP and the disk image. - -Procedure for validating Busybox boot test for RD-E1-Edge platform ------------------------------------------------------------------- - -After the build for busybox boot test is complete, the following command starts -the execution of the *RD-E1-Edge* fastmodel and the software boots up to the -busybox prompt. Examples on how to use the command are listed below. - -To boot up to the Busybox prompt, the command to be used is - - :: - - cd model-scripts/rdinfra - ./boot.sh -p rde1edge -a <additional_params> -n [true|false] - - -Supported command line options are listed below - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the boot test are as listed below. - - - :: - - ./boot.sh -p rde1edge - - - This command starts the execution of the RD-E1-Edge model and the - software boots up to the Busybox prompt. - - - :: - - ./boot.sh -p rde1edge -n true - - - This command starts the execution of the RD-E1-Edge model and the - software boots up to the Busybox prompt. The model supports - networking allowing the software running within the model to access - the network. - - - :: - - ./boot.sh -p rde1edge -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the RD-E1-Edge model with - networking enabled and the software boots up to the Busybox prompt. - Additional parameters to the model are supplied using the -a command - line parameter. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rde1edge/how-to/create-tap-interface.rst b/docs/rde1edge/how-to/create-tap-interface.rst deleted file mode 100644 index 92c0095..0000000 --- a/docs/rde1edge/how-to/create-tap-interface.rst +++ /dev/null @@ -1,59 +0,0 @@ -How to create tap interface to enable networking for FVPs -========================================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Context -------- - -RD-E1-Edge fast model supports virtual networking and it can interface with the -host PC network through the tap interface setup on the host machine. The steps -to setup a TAP interface on the host PC are listed below. This requires Ubuntu -16.04 or Ubuntu 18.04 as the host PC. - - -How to setup tap interface --------------------------- - -- Install the ``bridge-utils`` package - - :: - - sudo apt-get install bridge-utils - -- The first step is to create a bridge and add the host PC network as its - interface. Here, ``br0`` is the bridge name and ``enp0s3`` is the host PC - network device name. Replace these names with the names of the interfaces - used on the host PC. - - :: - - sudo brctl addbr br0 - sudo brctl addif br0 enp0s3 - sudo ifconfig enp0s3 0.0.0.0 - sudo ifconfig br0 up - sudo dhclient br0 - -- Next setup is to add the tap interface. Here, ``tap0`` is the name of the tap - interface. - - :: - - sudo ip tuntap add dev tap0 mode tap user $(whoami) - sudo ifconfig tap0 0.0.0.0 promisc up - sudo brctl addif br0 tap0 - -Note: These steps do not make a persistent instance of the bridge and the tap -interface. After the host PC reboots, these steps have to be repeated again. - -Refer `this documentation <https://wiki.linuxfoundation.org/networking/bridge>`_ -for more details. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rde1edge/how-to/debian-test.rst b/docs/rde1edge/how-to/debian-test.rst deleted file mode 100644 index 5c0e81a..0000000 --- a/docs/rde1edge/how-to/debian-test.rst +++ /dev/null @@ -1,223 +0,0 @@ -How to build RD-E1-Edge platform software to install and boot Debian distribution -================================================================================= - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Debian distribution boot support --------------------------------- -RD-E1-Edge software stack supports the installation and boot of Debian 9.8 -Stretch Distribution (Debian 9.8 Distribution). The Debian distribution is -installed on a SATA disk and the installed image can be used for multiple boots. - - -Procedure to build RD-E1-Edge software stack for debian boot ------------------------------------------------------------- - -The RD-E1-Edge platform software stack has to be first built to prepare for the -debian distribution installation step. The procedure to execute the RD-E1-Edge -platform stack is listed below. - -To build the RD-E1-Edge software stack, the command to be used is - - - :: - - ./build-scripts/build-test-uefi.sh -p rde1edge <command> - - - Supported command line options are listed below - - - <command> - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -An example of the command to begin the installation of the debian distribution -is listed below. - - - :: - - ./build-scripts/build-test-uefi.sh -p rde1edge all - - - This command cleans, builds and packages the RD-E1-Edge software stack - needed for the Debian installation/boot test for RD-E1-Edge platform. - - - :: - - ./build-scripts/build-test-uefi.sh -p rde1edge build - - - This command performs an incremental build of the software components - included in the software stack for the RD-E1-Edge platform. Note: this - command should be followed by the ``package`` command to complete the - preparation of the FIP image. - - - :: - - ./build-scripts/build-test-uefi.sh -p rde1edge package - - - This command packages the previously built software stack and prepares - the FIP image. - - -Procedure for installing Debian distro on RD-E1-Edge platform -------------------------------------------------------------- - -After the build for the distro is complete, Debian can be installed into a -SATA disk image. Before beginning the installation process download the iso -image of the required debian version. For example, Debian 9.8 Strech CD ISO -image can be downloaded from `here <https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/>`_ -or with this `direct link <https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/debian-9.8.0-arm64-xfce-CD-1.iso>`_. - -The command used to begin the distro installation is: - - :: - - cd model-scripts/rdinfra - ./distro.sh -p rde1edge -i <iso_image_path> -s <disk size> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -i <iso_image_path> - - - Path to the downloaded installer iso image. - - - -s <disk_size> - - - Size of the SATA disk image (in GB) to be created. 4GB and above is - good enough for most use cases. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -An example of the command to begin the boot of the debian distribution is -listed below. - - - :: - - ./distro.sh -p rde1edge -i ./debian-9.8.0-arm64-xfce-CD-1.iso -s 4 - - - This command creates a 4GB SATA disk image, boots the RD-E1-Edge - software stack and start the installation of debian distro. - - - The RD-E1-Edge platform supports a total of 8GB of DDR memory out of - which 6GB of memory is located above the 32-bit memory space. The debian - installation fails if the upper 6GB is enabled. To disable the use of - the upper 6GB, at the grub menu displayed during the installation, - edit the kernel boot parameters as below for enabling earlycon output - and limiting the DDR memory to 2032MB (2GB - 16MB) for SATA disk - detection. - - :: - - setparams 'Install' - set background_color=black - linux /install.a64/vmlinuz mem=2032M earlycon=pl011,0x7ff80000 console=ttyAMA0,115200 - initrd /intsall.a64/initrd.gz - - - From here on, follow the instructions of the Debian installer. For more - information about the installation procedure, please refer this - `link <https://www.debian.org/releases/stable/arm64/index.html.en>`_. - - - During installation, the installer will prompt the user with the message - 'Load CD-ROM drivers from removable media' and display two options - - Yes/No. - - - Select the option 'No' which would again display two options - - Yes/No. - - Select the option 'Yes' which will display 'Automatic detection - did not find CD-ROM'. - - Module needed for accessing CD-ROM and display two options - - - none - - cdrom - - - Select the option 'none' and enter ``/dev/vda``. The installation - media on the virtio disk will be detected and installation - continues. - - - After the installation is completed, the disk image with a random name - "<number>.satadisk" will be created in model-scripts/rdinfra/ folder. - User should use this disk image when booting the Debian distribution. - - -Procedure for booting Debian distro on RD-E1-Edge platform ----------------------------------------------------------- - -To boot the debian distro, use the following command: - - :: - - cd model-scripts/rdinfra - ./distro.sh -p rde1edge -d <satadisk_path> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -d <satadisk_path> - - - Path to the installed SATA disk image created using the previous - section. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands are as listed below. - - - :: - - ./distro.sh -p rde1edge - - - This command looks for the available .satadisk image in the - ``model-scripts/rdinfra`` folder and boots with that image. If multiple - .satadisk images are found, it will list them all but won't boot. - - - :: - - ./distro.sh -p rde1edge -d ./debian.satadisk - - - This command begins the distro boot from the ``debian.satadisk`` image. - - - During boot, at the grub menu, edit the kernel boot parameters as below for - enabling earlycon output and limiting the DDR memory to 2032MB for - SATA disk detection - - :: - - setparams 'Install' - set background_color=black - linux /install.a64/vmlinuz mem=2032M earlycon=pl011,0x7ff80000 console=ttyAMA0,115200 - initrd /intsall.a64/initrd.gz - - Save and exit the grub menu. The boot will then continue up to the login - prompt. - - -This completes the validation of the Debian distribution installation and boot -functionalities. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rde1edge/how-to/fedora-test.rst b/docs/rde1edge/how-to/fedora-test.rst deleted file mode 100644 index a3fe016..0000000 --- a/docs/rde1edge/how-to/fedora-test.rst +++ /dev/null @@ -1,177 +0,0 @@ -How to build RD-E1-Edge platform software to install and boot Fedora distribution
-=================================================================================
-
-.. section-numbering::
- :suffix: .
-
-.. contents::
-
-
-Fedora distribution boot support
---------------------------------
-RD-E1-Edge software stack supports the installation and boot of Fedora Enterprise
-Server Distribution (Fedora 27 Distribution). The Fedora distribution is
-installed on a SATA disk and the installed image can be used for multiple boots.
-
-
-Procedure to build RD-E1-Edge software stack for Fedora boot
-------------------------------------------------------------
-
-The RD-E1-Edge platform software stack has to be first built to prepare for the
-Fedora distribution installation step. The procedure to execute the RD-E1-Edge
-platform stack is listed below.
-
-To build the RD-E1-Edge software stack, the command to be used is
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rde1edge <command>
-
- - Supported command line options are listed below
-
- - <command>
-
- - ``clean``
- - ``build``
- - ``package``
- - ``all`` (all the three above)
-
-
-An example of the command to begin the installation of the Fedora distribution
-is listed below.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rde1edge all
-
- - This command cleans, builds and packages the RD-E1-Edge software stack
- needed for the Fedora installation/boot test for RD-E1-Edge platform.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rde1edge build
-
- - This command performs an incremental build of the software components
- included in the software stack for the RD-E1-Edge platform. Note: this
- command should be followed by the ``package`` command to complete the
- preparation of the fip image.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rde1edge package
-
- - This command packages the previously build software stack and prepares
- the fip image.
-
-
-Procedure for installing Fedora distro on RD-E1-Edge platform
--------------------------------------------------------------
-
-After the build for the distro is complete, Fedora can be installed into a
-SATA disk image. Before beginning the installation process download the iso
-image of the required Fedora version. For example, the Fedora distribution iso image
-has to be downloaded from `here <https://dl.fedoraproject.org/pub/fedora-secondary/releases/27/Server/aarch64/iso/>`_
-or with this `direct link <https://dl.fedoraproject.org/pub/fedora-secondary/releases/27/Server/aarch64/iso/Fedora-Server-dvd-aarch64-27-1.6.iso>`_.
-
-The command used to begin the distro installation is:
-
- ::
-
- cd model-scripts/rdinfra
- ./distro.sh -p rde1edge -i <iso_image_path> -s <disk size> -a <additional_params> -n [true|false]
-
-Supported command line options are listed below
-
- - -i <iso_image_path>
-
- - Path to the downloaded installer iso image.
-
- - -s <disk_size>
-
- - Size of the SATA disk image (in GB) to be created. 4GB and above is
- good enough for most use cases.
-
- - -n [true|false] (optional)
-
- - Controls the use of network ports by the model. If network ports have
- to be enabled, use 'true' as the option. Default value is set to
- 'false'.
-
- - -a <additional_params>
-
- - Specify any additional model parameters to be passed. The model
- parameters and the data to be passed to those parameters can be found
- in the FVP documentation.
-
-
-An example of the command to begin the boot of the Fedora distribution is
-listed below.
-
- - ::
-
- ./distro.sh -p rde1edge -i ./Fedora-Server-dvd-aarch64-27-1.6.iso -s 4
-
- - This command creates a 4GB SATA disk image, boot the RD-E1-Edge software
- stack and start the installation of Fedora distro.
-
- - From here on, follow the instructions of the Fedora installer. For more
- information about the installation procedure, please refer this
- `link <https://docs.fedoraproject.org/en-US/index.html>`_.
-
- - After the installation is completed, the disk image with a random name
- "<number>.satadisk" will be created in model-scripts/rdinfra/ folder. User
- should use this disk image when booting the Fedora distribution.
-
-
-Procedure for booting Fedora distro on RD-E1-Edge platform
-----------------------------------------------------------
-
-To boot the Fedora distro, use the following command:
-
- ::
-
- cd model-scripts/rdinfra
- ./distro.sh -p rde1edge -d <satadisk_path> -a <additional_params> -n [true|false]
-
-Supported command line options are listed below
-
- - -d <satadisk_path>
-
- - Path to the installed SATA disk image created using the previous
- section.
-
- - -n [true|false] (optional)
-
- - Controls the use of network ports by the model. If network ports have
- to be enabled, use 'true' as the option. Default value is set to
- 'false'.
-
- - -a <additional_params>
-
- - Specify any additional model parameters to be passed. The model
- parameters and the data to be passed to those parameters can be found
- in the FVP documentation.
-
-
-Example command functionality are as listed below.
-
- - ::
-
- ./distro.sh -p rde1edge
-
- - This command looks for the available .satadisk image in the
- ``model-scripts/rdinfra`` folder and boots with that image. If multiple
- .satadisk images are found, it will list them all but won't boot.
-
- - ::
-
- ./distro.sh -p rde1edge -d ./fedora.satadisk
-
- - This command begins the distro boot from the ``fedora.satadisk`` image.
-
-This completes the validation of the Fedora distribution installation and boot
-functionalities.
-
---------------
-
-*Copyright (c) 2019, Arm Limited. All rights reserved.*
diff --git a/docs/rde1edge/how-to/kvm-test.rst b/docs/rde1edge/how-to/kvm-test.rst deleted file mode 100644 index 95c11f1..0000000 --- a/docs/rde1edge/how-to/kvm-test.rst +++ /dev/null @@ -1,189 +0,0 @@ -How to build RD-E1-Edge platform software to validate KVM feature -================================================================= - -.. section-numbering:: - :suffix: . - -.. contents:: - -What is KVM ------------ - -Kernel Virtual Machine (KVM) is a virtualization module built in the linux -kernel which lets the user to turn linux into a hypervisor to allow hosting -single/multiple isolated guests or virtual machine. KVM requires a processor -with hardware virtualization extensions. - -Currently, KVM is part of linux kernel. Some of the features of KVM are: - -- Over-committing : KVM allows to allocate more virtualized CPU or memory - for the virtual machine than that of the host. -- Thin provisioning : KVM allows to allocate and optimize the flexible - storage for the virtual machines. -- Disk throttling : KVM allows to set limits for disk I/O requests. -- Virtual CPU hot plug: KVM allows ability to increase the CPU count of the - virtual machine during run time. - - -What does KVM test on RD-E1-Edge demonstrate --------------------------------------------- - -The RD-E1-Edge platform demonstrates boot up 2+ instances of guest OS's using -`lvkm tool <https://github.com/lkvm/lkvm>`_. Linux KVM tool supports booting -guest OS's of the same architecture. For RD-E1-Edge booting only ARM based -virtual machine is supported. KVM test for RD-E1-Edge demonstrates booting -Linux Kernel v4.18 or Linux Kernel v4.13 as guest with Linux Kernel v4.18 as -the host. - - -Procedure to build KVM test for RD-E1-Edge platform ---------------------------------------------------- - -Execution of the KVM test requires booting a Fedora distribution system with the -kernel built for the RD-E1-Edge platform. The first step would be to -get a `installed Fedora distribution`_ satadisk image and `prepare the image`_. -After the Fedora satadisk image has been prepared, the ``fedora.satadisk`` image -file has to be placed in the ``prebuilts/refinfra`` directory. Now, build the -firmware components and the kernel image needed for running the KVM test. For -generation of these image, the build command to be used is listed below. - -To build the RD-N1-Edge software stack, the following command can be used - - :: - - ./build-scripts/rdinfra/build-test-kvm.sh -p rde1edge <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/rdinfra/build-test-kvm.sh -p rde1edge all - - - This command cleans, builds and packages the software stack needed - for the KVM test for RD-E1-Edge platform. - - - :: - - ./build-scripts/rdinfra/build-test-kvm.sh -p rde1edge build - - - This command performs an incremental build of the software components - included in the software stack for the RD-E1-Edge platform. Note: this - command should be followed by the 'package' command to complete the - preparation of the FIP and the disk image. - - - :: - - ./build-scripts/rdinfra/build-test-kvm.sh -p rde1edge package - - - This command packages the previously built software stack and prepares - the FIP and loads the kernel into the disk image. - - -Procedure for validating KVM test for RD-E1-Edge platform ---------------------------------------------------------- - -After the build for the KVM test is complete, to boot up to the Fedora login -prompt using the software stack, the command to be used is - - :: - - cd model-scripts/rdinfra - ./kvm.sh -p rde1edge -a <additional_params> -n [true|false] - -Note: ``fedora.satadisk`` is expected at the location ``prebuilts/refinfra`` for -this command to work. - -Supported command line options are listed below - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the KVM functionality are as listed below. - - - :: - - ./kvm.sh -p rde1edge - - - This command starts the execution of the RD-E1-Edge model and the - software boots up to the Fedora login prompt. - - - :: - - ./kvm.sh -p rde1edge -n true - - - This command starts the execution of the RD-E1-Edge model and the - software boots up to the Fedora login prompt. The model supports - networking allowing the software running within the model to access - the network. - - - :: - - ./kvm.sh -p rde1edge -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the RD-E1-Edge model with - networking enabled and the software boots up to the Fedora login prompt. - Additional parameters to the model are supplied using the -a command - line parameter. - - -During the system boot, select the 'Fedora (refinfra) 27 (Server Edition)' -kernel on the grub menu. After the boot is complete, login as the root user. - - - IMPORTANT: In the ``/root/`` directory, the lkvm executable is made - available as part of the `prepare fedora disk process`_. Before using - the lkvm tool, two dependencies (``glibc-static`` and ``libfdt-devel``) - need to be installed using the ``yum`` tool. This requires - `tap interface setup on the host`_ and the network parameter (``-n``) set - to be true while starting the test. Enabling the network interface allows - to model to connect to the internet through the network bridge interface - of the host PC. The command to install the dependencies for ``lkvm`` is: - - - :: - - yum install -y glibc-static libfdt-devel - - - After the dependencies are installed, kvm test can be done using the - following command: - - - :: - - ./lkvm run -k <path-to-linux-image> -c 8 --irqchip gicv3 -p "console=ttyS0,115200 earlycon=uart,mmio,0x3f8 debug" - - - For example to run the kernel on the kvm, following command can be used: - - - :: - - ./lkvm run -k /boot/vmlinux-refinfra -c 8 --irqchip gicv3 -p "console=ttyS0,115200 earlycon=uart,mmio,0x3f8 debug" - -This completes the validation of the KVM functionality. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - -.. _installed Fedora distribution: fedora-test.rst -.. _prepare the image: prepare-fedora-disk.rst -.. _prepare fedora disk process: prepare-fedora-disk.rst -.. _tap interface setup on the host: create-tap-interface.rst diff --git a/docs/rde1edge/how-to/prepare-fedora-disk.rst b/docs/rde1edge/how-to/prepare-fedora-disk.rst deleted file mode 100644 index a2aabe6..0000000 --- a/docs/rde1edge/how-to/prepare-fedora-disk.rst +++ /dev/null @@ -1,43 +0,0 @@ -How to prepare a fedora disk image for RAS and KVM test -======================================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Why to prepare the fedora disk image -------------------------------------- - -The RAS and KVM tests on the RD-E1-Edge platform requires a Fedora enterprise -linux as the root filesystem. The build and run scripts for these tests -require a pre-installed disk image of Fedora 27 to be present in the -prebuilts/refinfra directory. This pre-installed disk image can then be -preloaded with all the tools required to validate the KVM and RAS tests. - -Preparing the fedora disk image -------------------------------- - -- Install a Fedora 27 Enterprise Linux distribution disk image. Refer to - [refer] for detailed instructions on this. - -- Create the directory ``prebuilts/refinfra`` (if that does not exist) at the - root of the workspace. - -- Copy the installed fedora disk image at ``prebuilts/refinfra/fedora.satadisk`` - -- Use the following command to update the grub menu, download/unpack/load the - lvkm executable to the /root/ directory of the fedora disk. - Note: sudo permission is required for completing this step. - - :: - - sudo ./build-scripts/rdinfra/prepare-fedora-disk.sh - -This completes the procedure to prepare the fedora disk image. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rde1edge/how-to/ras-test.rst b/docs/rde1edge/how-to/ras-test.rst deleted file mode 100644 index a3d84ed..0000000 --- a/docs/rde1edge/how-to/ras-test.rst +++ /dev/null @@ -1,194 +0,0 @@ -How to build RD-E1-Edge platform software to validate platform RAS error handling -================================================================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - -What is RAS ------------ - -Reliability Availability and Serviceability are three aspects that are -considered to be vital to ensure correct functioning of a server system. These -require extensive support in the platform hardware and software to ensure that -the system is producing correct results and that in a scenario where the system -encounters a malfunctioning component, the system is able to: - - - identify and correct the error condition - - record and flag errors to an external component like a Board Management - Controller (BMC) - - provide for mechanisms to avoid or keep to a minimum, the system downtime - by supporting features like hot-swapping of failing components, or by - providing for redundancy in the system hardware. - -What does RAS test on RD-E1-Edge demonstrate --------------------------------------------- - -The RD-E1-Edge platform supports multiple RAS error sources. Out of these, the -RAS error handling test validates the DMC-620 single-bit RAS error injection and -error handling of features in the platform software. The RAS error injection and -error handling requires multiple software components (kernel and firmware -components) to work in tandem in order for the RAS errors to be detected and -propogated to the kernel. This RAS test demonstrates the error injection and -error handling of the DMC-620 single-bit RAS error. - -Procedure to build RAS test for RD-E1-Edge platform ---------------------------------------------------- - -The RD-E1-Edge platform demonstrates the RAS feature by injecting a memory error -using RAS simulation capabilities in the DMC-620 controller. The RAS support -consists of the following components: - -- The DMC RAS driver. The driver executes as part of the S-EL0 Management Mode - and provides DMC RAS error handling and reporting. -- The TF-A SPM and SDEI modules which are responsible for handling system - interrupts and sending notifications to the DMC RAS driver and the Linux - kernel. -- APEI driver used to retrieve the system RAS errors from S-EL0 Management mode - code. This information is then used to populate the HEST ACPI table, for - future consumption by the Linux kernel. -- CPER Library which is used by individual RAS error handling drivers to - populate the CPER record with relevant data, to be passed on to the Linux - kernel on the non-secure side. -- The Linux kernel SDEI client which is part of the kernel ACPI APEI - notification mechanism. - -Execution of the RAS test requires booting a Fedora distribution system with the -kernel containing changes needed for the RAS test. The first step would be to -get a installed Fedora distribution satadisk image. After the Fedora SATA disk -image has been prepared, the Fedora.satadisk image file is created under the -prebuilts/refinfra directory. Now, build the firmware components and the kernel -image needed for running the RAS test. For generation of these image, the build -command to be used is listed below. - -To build the RD-E1-Edge software stack, the command to be used is - - :: - - ./build-scripts/rdinfra/build-test-ras.sh -p rde1edge <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/rdinfra/build-test-ras.sh -p rde1edge all - - - This command cleans, builds and packages the RD-E1-Edge software stack - needed for the RAS test for RD-E1-Edge platform. - - - :: - - ./build-scripts/rdinfra/build-test-ras.sh -p rde1edge build - - - This command performs an incremental build of the software components - included in the software stack for the RD-E1-Edge platform. Note: this - command should be followed by the 'package' command to complete the - preparation of the fip and the disk image. - - - :: - - ./build-scripts/rdinfra/build-test-ras.sh -p rde1edge package - - - This command packages the previously build software stack and prepares - the fip and the disk image. - -Procedure for validating RAS test for RD-E1-Edge platform ---------------------------------------------------------- - -After the build for the RAS test is complete, to boot upto the Fedora login -prompt using the RD-E1-Edge software stack, the command to be used is - - :: - - cd model-scripts/rdinfra - ./ras.sh -p rde1edge -n [true|false] -a <additional_params> - - -Supported command line options are listed below - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> (optional) - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the RAS functionality are as listed below. - - - :: - - ./ras.sh -p rde1edge - - - This command starts the execution of the RD-E1-Edge model and the - software boots upto the Fedora login prompt. - - - :: - - ./ras.sh -p rde1edge -n true - - - This command starts the execution of the RD-E1-Edge model and the - software boots upto the Fedora login prompt. The model supports - networking allowing the software running within the model to access the - network. - - - :: - - ./ras.sh -p rde1edge -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the RD-E1-Edge model with - networking enabled and the software boots upto the Fedora login - prompt. Additional parameters to the model are supplied using the -a - command line parameter. - - -During the system boot, select the 'Fedora (refinfra) 27 (Server Edition)' -kernel on the grub menu. On a successful login into Fedora, execute the -following command on the Fedora shell prompt to inject the DMC-620 single-bit -RAS error. - - :: - - 'echo 0x123 > /sys/kernel/debug/sdei_ras_poison' - -On execution of this command, the error record dump, known as CPER dump would be -seen on the Fedora terminal's console, similar to the sample dump shown below. - - :: - - [115792.848999] ghes_edac: Internal error: Can't find EDAC structure - [115792.849003] [Firmware Warn]: GHES: Invalid address in generic error data: 0x1f03fedcd - [115792.849008] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 - [115792.849013] {1}[Hardware Error]: event severity: recoverable - [115792.849017] {1}[Hardware Error]: Error 0, type: corrected - [115792.849021] {1}[Hardware Error]: fru_id: 00000000-0000-0000-0000-000000000000 - [115792.849025] {1}[Hardware Error]: fru_text: - [115792.849029] {1}[Hardware Error]: section_type: memory error - [115792.849033] {1}[Hardware Error]: physical_address: 0x00000001f03fedcd - [115792.849038] {1}[Hardware Error]: physical_address_mask: 0xfffffffffffff000 - [115792.849042] {1}[Hardware Error]: error_type: 8, parity error - -This completes the validation of the RAS functionality. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rde1edge/how-to/redhat-test.rst b/docs/rde1edge/how-to/redhat-test.rst deleted file mode 100644 index 609b194..0000000 --- a/docs/rde1edge/how-to/redhat-test.rst +++ /dev/null @@ -1,175 +0,0 @@ -How to build RD-E1-Edge platform software to install and boot Red Hat distribution
-==================================================================================
-
-.. section-numbering::
- :suffix: .
-
-.. contents::
-
-
-Red Hat distribution boot support
----------------------------------
-RD-E1-Edge software stack supports the installation and boot of Red Hat Enterprise
-Server Distribution (RHEL 7.4 Distribution). The Red Hat distribution is
-installed on a SATA disk and the installed image can be used for multiple boots.
-
-
-Procedure to build RD-E1-Edge software stack for Red Hat boot
--------------------------------------------------------------
-
-The RD-E1-Edge platform software stack has to be first built to prepare for the
-Red Hat distribution installation step. The procedure to execute the RD-E1-Edge
-platform stack is listed below.
-
-To build the RD-E1-Edge software stack, the command to be used is
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rde1edge <command>
-
- - Supported command line options are listed below
-
- - <command>
-
- - ``clean``
- - ``build``
- - ``package``
- - ``all`` (all the three above)
-
-
-An example of the command to begin the installation of the Red Hat distribution
-is listed below.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rde1edge all
-
- - This command cleans, builds and packages the RD-E1-Edge software stack
- needed for the Red Hat installation/boot test for RD-E1-Edge platform.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rde1edge build
-
- - This command performs an incremental build of the software components
- included in the software stack for the RD-E1-Edge platform. Note: this
- command should be followed by the ``package`` command to complete the
- preparation of the fip image.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rde1edge package
-
- - This command packages the previously build software stack and prepares
- the fip image.
-
-
-Procedure for installing Red Hat distro on RD-E1-Edge platform
---------------------------------------------------------------
-
-After the build for the distro is complete, Red Hat can be installed into a
-SATA disk image. Before beginning the installation process, contact Red Hat to
-obtain the RHEL 7.4 DVD installer image for AArch64 platform.
-
-The command used to begin the distro installation is:
-
- ::
-
- cd model-scripts/rdinfra
- ./distro.sh -p rde1edge -i <iso_image_path> -s <disk size> -a <additional_params> -n [true|false]
-
-Supported command line options are listed below
-
- - -i <iso_image_path>
-
- - Path to the downloaded installer iso image.
-
- - -s <disk_size>
-
- - Size of the SATA disk image (in GB) to be created. 4GB and above is
- good enough for most use cases.
-
- - -n [true|false] (optional)
-
- - Controls the use of network ports by the model. If network ports have
- to be enabled, use 'true' as the option. Default value is set to
- 'false'.
-
- - -a <additional_params>
-
- - Specify any additional model parameters to be passed. The model
- parameters and the data to be passed to those parameters can be found
- in the FVP documentation.
-
-
-An example of the command to begin the boot of the Red Hat distribution is
-listed below.
-
- - ::
-
- ./distro.sh -p rde1edge -i ./RHEL-ALT-7.4-20171030.0-Server-aarch64-dvd1.iso -s 4
-
- - This command creates a 4GB SATA disk image, boot the RD-E1-Edge software
- stack and start the installation of Red Hat distro.
-
- - From here on, follow the instructions of the Red Hat installer. For more
- information about the installation procedure, please refer this
- `link <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/>`_.
-
- - After the installation is completed, the disk image with a random name
- "<number>.satadisk" will be created in model-scripts/rdinfra/ folder. User
- should use this disk image when booting the Red Hat distribution.
-
-
-Procedure for booting Red Hat distro on RD-E1-Edge platform
------------------------------------------------------------
-
-To boot the Red Hat distro, use the following command:
-
- ::
-
- cd model-scripts/rdinfra
- ./distro.sh -p rde1edge -d <satadisk_path> -a <additional_params> -n [true|false]
-
-Supported command line options are listed below
-
- - -d <satadisk_path>
-
- - Path to the installed SATA disk image created using the previous
- section.
-
- - -n [true|false] (optional)
-
- - Controls the use of network ports by the model. If network ports have
- to be enabled, use 'true' as the option. Default value is set to
- 'false'.
-
- - -a <additional_params>
-
- - Specify any additional model parameters to be passed. The model
- parameters and the data to be passed to those parameters can be found
- in the FVP documentation.
-
-
-Example command functionality are as listed below.
-
- - ::
-
- ./distro.sh -p rde1edge
-
- - This command looks for the available .satadisk image in the
- ``model-scripts/rdinfra`` folder and boots with that image. If multiple
- .satadisk images are found, it will list them all but won't boot.
-
- - ::
-
- ./distro.sh -p rde1edge -d ./redhat.satadisk
-
- - This command begins the distro boot from the ``redhat.satadisk`` image.
-
-This completes the validation of the Red Hat distribution installation and boot
-functionalities.
-
---------------
-
-*Copyright (c) 2019, Arm Limited. All rights reserved.*
diff --git a/docs/rde1edge/how-to/secureboot-test.rst b/docs/rde1edge/how-to/secureboot-test.rst deleted file mode 100644 index e73f942..0000000 --- a/docs/rde1edge/how-to/secureboot-test.rst +++ /dev/null @@ -1,222 +0,0 @@ -How to build RD-E1-Edge platform software to validate Secure Boot -================================================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - -What is Secure Boot -------------------- - -Secure boot is a mechanism to build and maintain a complete chain of trust on -all the software layers executed in a system and preventing malicious code to be -stored and loaded in place of the authenticated one. When the device starts, the -firmware checks the signature of each piece of boot software, including UEFI -firmware drivers, EFI applications, and the operating system. If the signatures -are valid, the device boots, and the firmware gives control to the operating -system. Fundamental to the success of the secure boot is the ability to securely -store (also referred to as secure storage) and access the keys used for -authentication during the various stages of boot. - -Secure boot and Secure storage mechanisms are defined by the UEFI -specifications. In short, the UEFI specifications define the use of two -asymmetric key pairs, platform key (PK) and Key Exchange Key (KEK), and -databases for valid and black listed signatures. These keys and databases are -used during the secure boot phase which implies that the platform should provide -a tamper proof mechanism to store these keys. - -Secure boot support for RD-E1-Edge platform -------------------------------------------- - -The RD-E1-Edge platform software allows validation of the secure boot process. -Though secure boot process have to be validated using a linux distribution as -the target OS, the RD-E1-Edge platform software stack currently limits this feature -validation to boot of a signed busybox OS. There are pre-requisite packages to -be installed on the host PC to build the disk image to validate the secure boot -process. It is important that the following packages are installed prior to -building of the software stack for secure boot validation. The prerequisite -package installer script, if used, does install these packages as well. - -- efitools git repo is cloned and available at tools/efitools -- sbsign package is installed on to the local host system - -The next step is to create key pairs required for secure boot. The one-time -generation of the following key pairs are mandatory - PK, KEK, DB and DBX. The -following commands can be used to generate these key pairs. - -- Key Pair Creation : PK, KEK, DB and DBX - - :: - - cd tools/efitools - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=PK/" -keyout PK.key -out PK.crt -days 3650 -nodes -sha256 - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=KEK/" -keyout KEK.key -out KEK.crt -days 3650 -nodes -sha256 - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=DB_Key/" -keyout DB.key -out DB.crt -days 3650 -nodes -sha256 - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=DBX_Key/" -keyout DBX.key -out DBX.crt -days 3650 -nodes -sha256 - -- Convert crt certificate to der format - - :: - - openssl x509 -in PK.crt -outform der -out PK.der - openssl x509 -in KEK.crt -outform der -out KEK.der - openssl x509 -in DB.crt -outform der -out DB.der - openssl x509 -in DBX.crt -outform der -out DBX.der - -The signing of the grub and linux images are performed as a part of build script -“build-secureboot.sh”. There is no explicit user action required to sign these -images. - -Procedure to build secure boot test for RD-E1-Edge platforms ------------------------------------------------------------- - -The procedure to build the secure boot test along with the RD-E1-Edge platform software -stack is listed below. - -To build the RD-E1-Edge software stack, the command to be used is - - :: - - ./build-scripts/rdinfra/build-test-secureboot.sh -p rde1edge <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/rdinfra/build-test-secureboot.sh -p rde1edge all - - - This command cleans, builds and packages the RD-E1-Edge software stack needed - for the secure boot test for RD-E1-Edge platform. - - - :: - - ./build-scripts/rdinfra/build-test-secureboot.sh -p rde1edge build - - - This command performs an incremental build of the software components - included in the software stack for the RD-E1-Edge platform. Note: this - command should be followed by the 'package' command to complete the - preparation of the fip and the disk image. - - - :: - - ./build-scripts/rdinfra/build-test-secureboot.shh -p rde1edge package - - - This command packages the previously built software stack and prepares - the fip and the disk image. - - -Procedure to execute secure boot test on RD-E1-Edge platforms -------------------------------------------------------------- -The procedure to execute the secure boot test on the RD-E1-Edge platform is listed -below. - - :: - - cd model-scripts/rdinfra - ./secure_boot.sh -p rde1edge -a <additional_params> -n [true|false] - - -Supported command line options are listed below - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the secure boot functionality are as listed below. - - - :: - - ./secure_boot.sh -p rde1edge - - - This command starts the execution of the RD-E1-Edge model and the software - boots upto the busybox login prompt. - - - :: - - ./secure_boot.sh -p rde1edge -n true - - - This command starts the execution of the RD-E1-Edge model and the - software boots upto the busybox login prompt. The model supports - networking allowing the software running within the model to access - the network. - - - :: - - ./secure_boot.sh -p rde1edge -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the RD-E1-Edge model with networking - enabled and the software boots upto the busybox login prompt. Additional - parameters to the model are supplied using the -a command line - parameter. - -There are additional steps to be performed on the first boot to setup the secure -boot process. These steps are listed below. Ensure that these steps are executed -on the very first boot for validating the secure boot. - -- Interrupt the boot at EDK2 by pressing escape key and dropping into the EDK2 - boot menu. -- Select Device Manger -> Secure Boot Configuration -> Secure Boot Mode → - choose Custom mode and then press enter. -- Select "Custom Secure Boot Options” and then press enter. -- Select “DBX Options” -> "Enroll Signature" then press enter → - "Enroll Signature Using File" and the press enter → Select “NO VOLUME LEBEL” - and then press enter. -- Select EFI and press enter -> select BOOT and press enter → now Select - “DBX.der” and press enter -> “Commit Changes and Exit”. -- Repeat steps “d” and “e” for “DB options” for “DB.der”. -- Repeat steps “d” and “e” for “KEK options” for “KEK.der”. -- Repeat steps “d” and “e” for “PK options” for “PK.der”. -- Press Escape and press F10 to save. Ensure that the “Current Secure Boot - State” is set as “Enabled”. -- Press Escape and select the “continue” option. -- Prompts the user to press the “Enter”. Press Enter key which then reboots the - system -- Make sure to close the model using “Cross Mark” of “Fast Models -Clark” - windows after this, if model does not close then press “ctrl-c” to close it. - -Relaunch the model again, the platform boots up to busybox login prompt with -secure boot enabled. If the authentication of the grub or the linux kernel -fails, the boot fails and the user is notified about the authentication failure. - -To confirm that the boot is indeed a secure boot, the linux kernel messages -can be looked up. The following messages would appear in the linux boot log in -case of a secure linux kernel boot. - - :: - - Loading driver at 0x000F5D26000 EntryPoint=0x000F6D0AF80 - Loading driver at 0x000F5D26000 EntryPoint=0x000F6D0AF80 - EFI stub: Booting Linux Kernel... - EFI stub: UEFI Secure Boot is enabled. - EFI stub: Using DTB from configuration table - EFI stub: Exiting boot services and installing virtual address map... - [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd060] - -This completes the validation of the Secure boot functionality. - --------------- - -*Copyright (c) 2019, Arm Limited and Contributors. All rights reserved.* diff --git a/docs/rde1edge/how-to/setup-pxe-server.rst b/docs/rde1edge/how-to/setup-pxe-server.rst deleted file mode 100644 index 8357790..0000000 --- a/docs/rde1edge/how-to/setup-pxe-server.rst +++ /dev/null @@ -1,204 +0,0 @@ -How to setup PXE server on Ubuntu -================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Context -------- - -Preboot Execution Environment (PXE) boot is a standardized server-client -environment to boot an OS remotely through network. This allows multiple client -to install/boot OS remotely from a single server. All major distributions such -as Fedora, Ubuntu, Debian, Red Hat supports PXE boot. The virtio network device -available in the RD-E1-Edge platform can be leveraged to do PXE boot of linux -distributions. Ubuntu in particular allows installation through CDROM or PXE -only. To install Ubuntu on RD-E1-Edge Platform, PXE boot should be used. - -How to setup TFTP server ------------------------- - -Before beginning the installation, on the host PC (sever), TFTP, apache2 and -DHCP servers must be setup. The following steps can be used as reference to -setup the PXE server. - -- Download the required linux distribution network installer for arm64 - architecture. For example, the Ubuntu network installer for arm64 can be - downloaded from `here <http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/current/images/netboot/netboot.tar.gz>`_. - -- Extract the downloaded tar files - - :: - - tar -xvzf netboot.tar.gz - -- Install the TFTP server, DHCP server and dependencies - - :: - - sudo apt-get install apache2 tftpd-hpa inetutils-inetd isc-dhcp-server - -- Configure the PXE server to point the tftpboot directory - - - Open ``/etc/default/tftpd-hpa`` to edit - - :: - - sudo vi /etc/default/tftpd-hpa - - - Append the following lines to the end - - :: - - RUN_DAEMON="yes" - OPTIONS="-l -s /var/lib/tftpboot" - - - Open ``/etc/inetd.conf`` file to edit - - :: - - sudo vi /etc/inetd.conf - - - Append the following line to the end - - :: - - tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot - -- Copy the installer files into the ``/var/lib/tftpboot`` folder - - :: - - sudo cp -fr <ubuntu-installer-path> /var/lib/tftpboot/ - -- Copy the installer files into the apache2 folder - - :: - - sudo mkdir /var/www/html/ubuntu - sudo cp -fr <ubuntu-installer-path> /var/www/html/ubuntu/ - -- Restart the TFTF server - - :: - - sudo systemctl restart tftpd-hpa - -- Check the status of the TFTP server to see if it is active - - :: - - sudo systemctl status tftpd-hpa - - - - If the status is displayed as ``Stopped``, try the following commands - to start the TFTP server again - - :: - - sudo /etc/init.d/inetutils-inetd stop - sudo systemctl restart tftpd-hpa - sudo systemctl status tftpd-hpa - sudo /etc/init.d/inetutils-inetd start - sudo systemctl status tftpd-hpa - -This completes the setup of the TFTP server. - - -How to setup DHCP server ------------------------- - -- Verify whether the DHCP server is stopped - - :: - - sudo systemctl status isc-dhcp-server - - - If the status is shown as ``Running``, the service can be stopped by - using the following command - - :: - - sudo systemctl stop isc-dhcp-server - -- Follow the instructions on `how to create tap interface`_ to setup the tap - interface in the host PC. - -- Configure the DHCP server to point the grub config file (assuming the PXE - server and DHCP server are running on the same PC) - - :: - - sudo vi /etc/dhcp/dhcpd.conf - - - Add the following lines at the end - - :: - - ddns-update-style none; - log-facility local7; - - default-lease-time 600; - max-lease-time 7200; - - authoritative; - allow booting; - allow bootp; - - subnet 192.168.130.0 netmask 255.255.255.0 { - option routers 192.168.130.1; - option subnet-mask 255.255.255.0; - option broadcast-address 192.168.130.255; - option domain-name-servers 10.118.10.61; - option ntp-servers time.nist.gov; - option netbios-name-servers 192.168.130.1; - option netbios-node-type 2; - default-lease-time 86400; - max-lease-time 86400; - range 192.168.130.100 192.168.130.150; - filename "ubuntu-installer/arm64/bootnetaa64.efi"; - } - group { - next-server 10.162.0.155; - host tftp { - filename "ubuntu-installer/arm64/bootnetaa64.efi"; - hardware ethernet 00:02:F7:EF:50:A0; # Check your ethernet mac address - fixed-address 10.162.0.157; - } - } - - -- Add the following lines at the end of ``/etc/default/isc-dhcp-server`` - - :: - - INTERFACES="br0" - INTERFACESv4="br0" - INTERFACESv6="" - -- Restart the DHCP server - - :: - - sudo systemctl restart isc-dhcp-server - - - Check the status of the DHCP server - - :: - - sudo systemctl status isc-dhcp-server - -This completes the PXE setup on the host PC side. Following this, linux -distribution installation can be done through the network. For example, refer -`how to install Ubuntu on RD-E1-Edge`_ for the complete installation steps. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - -.. _how to create tap interface: create-tap-interface.rst -.. _how to install Ubuntu on RD-E1-Edge: ubuntu-test.rst diff --git a/docs/rde1edge/how-to/ubuntu-test.rst b/docs/rde1edge/how-to/ubuntu-test.rst deleted file mode 100644 index 0cf3405..0000000 --- a/docs/rde1edge/how-to/ubuntu-test.rst +++ /dev/null @@ -1,223 +0,0 @@ -How to build RD-E1-Edge platform software to install and boot Ubuntu distro -=========================================================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Ubuntu distribution boot support --------------------------------- -RD-E1-Edge software stack supports the installation and boot of Ubuntu 18.04 -Bionic distribution. The Ubuntu distribution is installed on a SATA disk and the -installed image can be used for multiple boots. - - -Procedure to build RD-E1-Edge software stack for Ubuntu boot ------------------------------------------------------------- - -The RD-E1-Edge platform software stack has to be first built to prepare for the -Ubuntu distribution installation step. The procedure to execute the RD-E1-Edge -platform stack is listed below. - -To build the RD-E1-Edge software stack, the command to be used is - - - :: - - ./build-scripts/build-test-uefi.sh -p rde1edge <command> - - - Supported command line options are listed below - - - <command> - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -An example of the command to begin the installation of the Ubuntu distribution -is listed below. - - - :: - - ./build-scripts/build-test-uefi.sh -p rde1edge all - - - This command cleans, builds and packages the RD-E1-Edge software stack - needed for the Ubuntu installation/boot test for RD-E1-Edge platform. - - - :: - - ./build-scripts/build-test-uefi.sh -p rde1edge build - - - This command performs an incremental build of the software components - included in the software stack for the RD-E1-Edge platform. Note: this - command should be followed by the ``package`` command to complete the - preparation of the fip image. - - - :: - - ./build-scripts/build-test-uefi.sh -p rde1edge package - - - This command packages the previously build software stack and prepares - the fip image. - - -Procedure for installing Ubuntu distro on RD-E1-Edge platform -------------------------------------------------------------- - -Ubuntu installer supports installation only through a CDROM disk. Hence, the -Ubuntu installation disk (ISO image) cannot be used with the RD-E1-Edge model. As -an alternate, Ubuntu can be installed through the PXE boot with the help of -the network installer which can be downloaded from `here <http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/current/images/netboot/netboot.tar.gz>`_. -Refer the `steps to setup PXE server`_ before beginning the installation. - -The following steps can be followed to begin the installation process. - -Create an empty disk image on which the Ubuntu installation will be done. - - :: - - cd model-scripts/rdinfra - dd if=/dev/zero of=<disk_image_name>.satadisk bs=1G count=<size in GB> - - - For example, use the following command to create a disk size of 4GB - - :: - - dd if=/dev/zero of=ubuntu_pxe.satadisk bs=1G count=4 - -The command to begin the installation is: - - :: - - ./distro.sh -p rde1edge -d <disk_image_name> -n [true|false] -a <additional_params> - - -Supported command line options are listed below - - - -d <disk_image_path> - - - Path to the created disk image on which Ubuntu will be installed. - - - -n [true|false] - - - Controls the use of network ports by the model. Since this installation - has to be done through the network, this must be set to 'true'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -An example of the command to begin the boot of the Ubuntu distribution is -listed below. - - - :: - - ./distro.sh -p rde1edge -d ./ubuntu_pxe.satadisk -n true - - - This command will start the RD-E1-Edge model and loads the edk2 - firmware. - - - After the console reaches loading of Tianocore edk2 firmware, press - escape to enter the UEFI menu and select the Boot Manager option. If - PXE setup is done correctly, you will see an option - ``UEFI PXEv4 (Mac:<random-mac-address>)``. Select the UEFI PXEv4 option - to continue the PXE boot. After few seconds, the model will acquire IP - address and find the tftp sever. - - - The RD-E1-Edge platform supports a total of 8GB of DDR memory out of - which 6GB of memory is located above the 32-bit memory space. The Ubuntu - installation fails if the upper 6GB is enabled. To disable the use of - the upper 6GB, at the grub menu displayed during the installation, - edit the kernel boot parameters as below limiting the DDR memory to - 2032MB (2GB - 16MB) for SATA disk detection. - - :: - - setparams 'Install' - set background_color=black - linux /ubuntu-installer/arm64/linux ---quiet ip=dhcp mem=2032m - initrd /ubuntu-installer/arm64/initrd.gz - - - - - From here on, follow the instructions of the Ubuntu installer. For more - information about the installation procedure, please refer this - `link <https://help.ubuntu.com/lts/installation-guide/arm64/ch06s03.html>`_. - - -Procedure for booting Ubuntu distro on RD-E1-Edge platform ----------------------------------------------------------- - -To boot the Ubuntu distro, use the following command: - - :: - - cd model-scripts/rdinfra - ./distro.sh -p rde1edge -d <satadisk_path> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -d <satadisk_path> - - - Path to the installed SATA disk image created using the previous - section. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example command functionality are as listed below. - - - :: - - ./distro.sh -p rde1edge - - - This command looks for the available .satadisk image in the - ``model-scripts/rdinfra`` folder and boots with that image. If multiple - .satadisk images are found, it will list them all but won't boot. - - - :: - - ./distro.sh -p rde1edge -d ./ubuntu_pxe.satadisk - - - This command begins the distro boot from the ``ubuntu_pxe.satadisk`` - image. - - - During boot, at the grub menu, edit the kernel boot parameters as below for - enabling earlycon output and limiting the DDR memory to 2032MB for - SATA disk detection - - :: - - setparams 'Install' - set background_color=black - linux /ubuntu-installer/arm64/linux mem=2032m earlycon=pl011,0x7ff80000 console=ttyAMA0,115200 - initrd /ubuntu-installer/arm64/initrd.gz - - Save and exit the grub menu. This boot will then continue up to the login - prompt. - - -This completes the validation of the Ubuntu distribution installation and boot -functionalities. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - -.. _steps to setup PXE server: setup-pxe-server.rst diff --git a/docs/rde1edge/user-guide.rst b/docs/rde1edge/user-guide.rst index 12d3175..797383f 100644 --- a/docs/rde1edge/user-guide.rst +++ b/docs/rde1edge/user-guide.rst @@ -1,235 +1,2 @@ -RD-E1-Edge platform user guide -============================== - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Introduction ------------- - -RD (Reference Design) is a collection of resources to provide a representative -view of typical compute subsystems that can be designed and implemented using -specific generations of Arm IP. RD-E1-Edge in particular is based on: - - - 16x `Neoverse E1 Cores <https://developer.arm.com/products/processors/neoverse/neoverse-e1>`_ - with DynamIQ Shared Unit (DSU). - - Dedicated L2 cache: 256KB per core - - Shared L3 cache: 2MB per cluster - - CMN-600 with CML option: 8MB System Level Cache and 16MB Snoop Filter - - DMC-620 with 2xRDIMM DDR4-3200 - - Multiple AXI expansion ports for I/O Coherent PCIe, Ethernet, offload - - Arm Cortex-M7 for System Control Processor (SCP) and - Manageability Control Processor (MCP) - -This document is a user guide on how to setup, build and run the software stack -of RD-E1-Edge on Fixed Virtual Platform. - - -Host machine requirements -------------------------- - -The minimum recommended host PC specification for building the software stack -and running the RD-E1-Edge FVP model is a dual-core processor running at 2GHz with -8GB of RAM. For best performance, use a machine with a quad-core processor -running at 2.6GHz with 16GB of RAM with free hard disk space of at least 64GB. - -The software package has been tested on **Ubuntu 16.04 LTS (64-bit)** and -**Ubuntu 18.04 LTS (64-bit)**. This guide assumes that the user is on either of -this operating system. - - -Repo tool setup ---------------- - -The software stack for RD-E1-Edge is available in multiple git repositories. In -order to simplify downloading the software stack for RD-E1-Edge platform, `repo tool <https://source.android.com/setup/develop/repo>`_ -can be used. This section explains how to setup git and repo tool. - -- Install Git by using the following command - - :: - - sudo apt-get install git - -- Git installation can be confirmed by checking the version - - :: - - git --version - - This should return the git version in a format such as ``git version 2.7.4`` - -- Set name and email address in git - - :: - - git config --global user.name "<your-name>" - git config --global user.email "<your-email@example.com>" - -- Download the repo tool - - :: - - sudo apt-get install repo - -This completes the setup of the repo tool. - - -Syncing the software stack --------------------------- - -The manifest file, which contains the location of all the git repositories of -RD-E1-Edge software stack, is available `here <https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git/>`_. -This section explains how to sync the software stack. - -- Switch to a new folder - - :: - - mkdir rde1edge - cd rde1edge - -- For obtaining the latest *stable* software stack, use the following commands - to sync: - - :: - - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m pinned-rde1edge.xml -b refs/tags/<RELEASE_TAG> - repo sync -j $(nproc) --fetch-submodules --force-sync - - Note: The RELEASE_TAG can be found in the release notes, if obtained. If - a release note is not available, or if a RELEASE_TAG is not known, see the - section "Release Tags" below to obtain the most recent release tag. - -- For obtaining the software stack with latest *upstream updates* but which - might not have been fully validated, use the following commands to sync: - - :: - - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m rde1edge.xml -b master - repo sync -j $(nproc) --fetch-submodules --force-sync - -This will download the RD-E1-Edge software stack into the ``rde1edge`` folder. - - -Installing prerequisites ------------------------- - -Run the following command to install all the required prerequisites to build the -software stack: - - :: - - sudo ./build-scripts/rdinfra/install_prerequisites.sh - -It is mandatory to execute this script at least once before build and executing -the software stack. - - -Downloading the GCC toolchain binaries --------------------------------------- - -In addition to the prerequisites installed, gcc toolchain binaries have to be -downloaded and placed at the ``tools/gcc`` folder. Use the following commands -to download and untar the binaries: - - :: - - # Move to the rde1edge software stack directory - cd rde1edge - - # Create a folder for gcc under tools folder - mkdir -p tools/gcc - cd tools/gcc - - # Download and extract the binaries - wget https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/aarch64-linux-gnu/gcc-linaro-6.2.1-2016.11-x86_64_aarch64-linux-gnu.tar.xz - tar -xJf gcc-linaro-6.2.1-2016.11-x86_64_aarch64-linux-gnu.tar.xz - wget https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/arm-linux-gnueabihf/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf.tar.xz - tar -xJf gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf.tar.xz - wget https://armkeil.blob.core.windows.net/developer//sitecore/shell/-/media/Files/downloads/gnu-rm/5_4-2016q3/gcc-arm-none-eabi-5_4-2016q3-20160926-linux,-d-,tar.bz2 - tar -xjf gcc-arm-none-eabi-5_4-2016q3-20160926-linux,-d-,tar.bz2 - -This completes the setup of the GCC toolchain binaries. - - -Obtaining the RD-E1-Edge Fast Model ------------------------------------ - -User can request for the latest version of RD-E1-Edge Fast Model through -`this page <https://developer.arm.com/products/system-design/fixed-virtual-platforms>`_ -or contact arm directly at this email address: `support-connect@arm.com <mailto:support-connect@arm.com>`_. - -Follow the instruction in the installer and setup the FVP. Typically, the -installer will ask to create a new folder in the home directory. You can either -install the FVP in the home folder, or in the ``fastmodel/refinfra`` folder -inside the ``rde1edge`` folder. If you would like to install in the -``fastmodel/refinfra`` folder, when asked for the install location, -enter as ``fastmodel/refinfra``. - -Before launching any scripts from ``model-scripts`` folder, export the absolute -path of the model as an environment variable. - - :: - - export MODEL=<absolute-path-of-the-model-executable> - -This completes the steps to obtain the RD-E1-Edge Fast Model. - - -Supported Features ------------------- - -RD-E1-Edge software stack supports number of tests to explore its features. To -begin with, one can start with the busybox boot, and then try installing and -booting various linux distribution. RD-E1-Edge is target for infrastructure -platforms and it supports variety of infrastructure specific features. All the -supported tests are listed below: - - 1. Supported Filesystems: - a. `Busybox`_ - b. `Fedora 27 Enterprise Linux Distribution`_ - c. `Debian 9.8.0 Enterprise Linux Distribution`_ - d. `Ubuntu 18.4 Enterprise Linux Distribution`_ - 2. Supported Tests: - a. `KVM`_ - - -Release Tags ------------- - -Most recent release tag: - - RD-E1-Edge platform: RD-INFRA-2020.09.30 - -Here's the list of release tags and corresponding Fast Model version supported: - -+-----------------------+-------------------------+ -| Release Tag | RD-E1-Edge FVP Version | -+=======================+=========================+ -| RD-INFRA-2020.09.30 | 11.12.43 | -+-----------------------+-------------------------+ -| | | -+-----------------------+-------------------------+ -| | | -+-----------------------+-------------------------+ -| | | -+-----------------------+-------------------------+ -| | | -+-----------------------+-------------------------+ - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - - -.. _Busybox: how-to/busybox-boot.rst -.. _Fedora 27 Enterprise Linux Distribution: how-to/fedora-test.rst -.. _Debian 9.8.0 Enterprise Linux Distribution: how-to/debian-test.rst -.. _Ubuntu 18.4 Enterprise Linux Distribution: how-to/ubuntu-test.rst -.. _KVM: how-to/kvm-test.rst -.. _RAS: how-to/ras-test.rst -.. _Secure Boot: how-to/secureboot-test.rst +RD-E1-Edge platform documentation has been migrated to +https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/tree/master/docs/infra diff --git a/docs/rdn1edge/acs-results/rdn1edge-fwts.log b/docs/rdn1edge/acs-results/rdn1edge-fwts.log deleted file mode 100755 index b26d431..0000000 --- a/docs/rdn1edge/acs-results/rdn1edge-fwts.log +++ /dev/null @@ -1,1390 +0,0 @@ -1.1 fwts Arm INFO ACS Version: v2.5 -1.1 fwts Results INFO generated by fwts: Version V20.07.00 (2020-07-29 07:32:51). -1.1 fwts Some INFO of this work - Copyright (c) 1999 - 2020, Intel Corp. All rights reserved. -1.1 fwts Some INFO of this work - Copyright (c) 2010 - 2020, Canonical. -1.1 fwts Some INFO of this work - Copyright (c) 2016 - 2020, IBM. -1.1 fwts Some INFO of this work - Copyright (c) 2017 - 2020, ARM Ltd. -1.1 fwts This INFO test run on 21/09/20 at 15:40:52 on host Linux qemuarm64 4.18.0-luv #1 SMP -1.1 fwts PREEMPT INFO Tue Sep 15 08:17:16 UTC 2020 aarch64. -1.1 fwts Command: INFO "fwts -r stdout -q --sbbr". -1.1 fwts Running INFO tests: acpiinfo uefirtmisc uefirtvariable uefirttime dmicheck xsdt spcr -1.1 fwts rsdp_sbbr INFO method madt hest gtdt fadt_sbbr acpi_rc acpi_ged dbg2 acpi_sbbr -1.1 fwts acpitables. INFO acpitables. -1.1 fwts acpiinfo: INFO General ACPI information test. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 3: Determine Kernel ACPI version. -1.1 fwts Test INFO 2 of 3: Determine machine's ACPI version. -1.1 fwts No INFO FACS found, fwts has faked one instead. -1.1 fwts FACP INFO ACPI Version: 6.2 -1.1 fwts Test INFO 3 of 3: Determine AML compiler. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 0 INFO passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 1 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts uefirtmisc: INFO UEFI miscellaneous runtime service interface tests. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 4: Test for UEFI miscellaneous runtime service interfaces. -1.1 fwts Testing INFO UEFI runtime service GetNextHighMonotonicCount interface. -1.1 fwts PASSED: INFO Test 1, UEFI runtime service GetNextHighMonotonicCount interface test -1.1 fwts passed. INFO passed. -1.1 fwts Testing INFO UEFI runtime service QueryCapsuleCapabilities interface. -1.1 fwts SKIPPED: INFO Test 1, Not support the UEFI QueryCapsuleCapabilities runtime interface -1.1 fwts with INFO flag value 0x0: cannot test. -1.1 fwts ADVICE: INFO Firmware also needs to check if the revision of system table is correct -1.1 fwts or INFO not. Linux kernel returns EFI_UNSUPPORTED as well, if the FirmwareRevision of -1.1 fwts system INFO table is less than EFI_2_00_SYSTEM_TABLE_REVISION. -1.1 fwts SKIPPED: INFO Test 1, Not support the UEFI QueryCapsuleCapabilities runtime interface -1.1 fwts with INFO flag value 0x10000: cannot test. -1.1 fwts ADVICE: INFO Firmware also needs to check if the revision of system table is correct -1.1 fwts or INFO not. Linux kernel returns EFI_UNSUPPORTED as well, if the FirmwareRevision of -1.1 fwts system INFO table is less than EFI_2_00_SYSTEM_TABLE_REVISION. -1.1 fwts SKIPPED: INFO Test 1, Not support the UEFI QueryCapsuleCapabilities runtime interface -1.1 fwts with INFO flag value 0x30000: cannot test. -1.1 fwts ADVICE: INFO Firmware also needs to check if the revision of system table is correct -1.1 fwts or INFO not. Linux kernel returns EFI_UNSUPPORTED as well, if the FirmwareRevision of -1.1 fwts system INFO table is less than EFI_2_00_SYSTEM_TABLE_REVISION. -1.1 fwts SKIPPED: INFO Test 1, Not support the UEFI QueryCapsuleCapabilities runtime interface -1.1 fwts with INFO flag value 0x50000: cannot test. -1.1 fwts ADVICE: INFO Firmware also needs to check if the revision of system table is correct -1.1 fwts or INFO not. Linux kernel returns EFI_UNSUPPORTED as well, if the FirmwareRevision of -1.1 fwts system INFO table is less than EFI_2_00_SYSTEM_TABLE_REVISION. -1.1 fwts SKIPPED: INFO Test 1, Not support the UEFI QueryCapsuleCapabilities runtime interface -1.1 fwts with INFO flag value 0x70000: cannot test. -1.1 fwts ADVICE: INFO Firmware also needs to check if the revision of system table is correct -1.1 fwts or INFO not. Linux kernel returns EFI_UNSUPPORTED as well, if the FirmwareRevision of -1.1 fwts system INFO table is less than EFI_2_00_SYSTEM_TABLE_REVISION. -1.1 fwts Test INFO 2 of 4: Stress test for UEFI miscellaneous runtime service interfaces. -1.1 fwts Stress INFO testing for UEFI runtime service GetNextHighMonotonicCount interface. -1.1 fwts PASSED: INFO Test 2, UEFI runtime service GetNextHighMonotonicCount interface stress -1.1 fwts test INFO passed. -1.1 fwts Stress INFO testing UEFI runtime service QueryCapsuleCapabilities interface. -1.1 fwts SKIPPED: INFO Test 2, Not support the UEFI QueryCapsuleCapabilities runtime interface -1.1 fwts with INFO flag value 0x0: cannot test. -1.1 fwts ADVICE: INFO Firmware also needs to check if the revision of system table is correct -1.1 fwts or INFO not. Linux kernel returns EFI_UNSUPPORTED as well, if the FirmwareRevision of -1.1 fwts system INFO table is less than EFI_2_00_SYSTEM_TABLE_REVISION. -1.1 fwts SKIPPED: INFO Test 2, Not support the UEFI QueryCapsuleCapabilities runtime interface -1.1 fwts with INFO flag value 0x10000: cannot test. -1.1 fwts ADVICE: INFO Firmware also needs to check if the revision of system table is correct -1.1 fwts or INFO not. Linux kernel returns EFI_UNSUPPORTED as well, if the FirmwareRevision of -1.1 fwts system INFO table is less than EFI_2_00_SYSTEM_TABLE_REVISION. -1.1 fwts SKIPPED: INFO Test 2, Not support the UEFI QueryCapsuleCapabilities runtime interface -1.1 fwts with INFO flag value 0x30000: cannot test. -1.1 fwts ADVICE: INFO Firmware also needs to check if the revision of system table is correct -1.1 fwts or INFO not. Linux kernel returns EFI_UNSUPPORTED as well, if the FirmwareRevision of -1.1 fwts system INFO table is less than EFI_2_00_SYSTEM_TABLE_REVISION. -1.1 fwts SKIPPED: INFO Test 2, Not support the UEFI QueryCapsuleCapabilities runtime interface -1.1 fwts with INFO flag value 0x50000: cannot test. -1.1 fwts ADVICE: INFO Firmware also needs to check if the revision of system table is correct -1.1 fwts or INFO not. Linux kernel returns EFI_UNSUPPORTED as well, if the FirmwareRevision of -1.1 fwts system INFO table is less than EFI_2_00_SYSTEM_TABLE_REVISION. -1.1 fwts SKIPPED: INFO Test 2, Not support the UEFI QueryCapsuleCapabilities runtime interface -1.1 fwts with INFO flag value 0x70000: cannot test. -1.1 fwts ADVICE: INFO Firmware also needs to check if the revision of system table is correct -1.1 fwts or INFO not. Linux kernel returns EFI_UNSUPPORTED as well, if the FirmwareRevision of -1.1 fwts system INFO table is less than EFI_2_00_SYSTEM_TABLE_REVISION. -1.1 fwts Test INFO 3 of 4: Test GetNextHighMonotonicCount with invalid NULL parameter. -1.1 fwts PASSED: INFO Test 3, Test with invalid NULL parameter returned EFI_INVALID_PARAMETER -1.1 fwts as INFO expected. -1.1 fwts Test INFO 4 of 4: Test UEFI miscellaneous runtime services supported status. -1.1 fwts SKIPPED: INFO Test 4, Cannot get the RuntimeServicesSupported variable, maybe the -1.1 fwts runtime INFO service GetVariable is not supported or RuntimeServicesSupported not -1.1 fwts provided INFO by firmware. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 3 INFO passed, 0 failed, 0 warning, 0 aborted, 11 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts uefirtvariable: INFO UEFI Runtime service variable interface tests. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 9: Test UEFI RT service get variable interface. -1.1 fwts PASSED: INFO Test 1, UEFI runtime service GetVariable interface test passed. -1.1 fwts Test INFO 2 of 9: Test UEFI RT service get next variable name interface. -1.1 fwts The INFO runtime service GetNextVariableName interface function test. -1.1 fwts PASSED: INFO Test 2, The runtime service GetNextVariableName interface function test -1.1 fwts passed. INFO passed. -1.1 fwts Check INFO the GetNextVariableName returned value of VariableNameSize is equal to the -1.1 fwts length INFO of VariableName. -1.1 fwts PASSED: INFO Test 2, Check the GetNextVariableName returned value of VariableNameSize -1.1 fwts is INFO equal to the length of VariableName passed. -1.1 fwts Test INFO GetNextVariableName interface returns unique variables. -1.1 fwts PASSED: INFO Test 2, Test GetNextVariableName interface returns unique variables -1.1 fwts passed. INFO passed. -1.1 fwts The INFO GetNextVariableName interface conformance tests. -1.1 fwts PASSED: INFO Test 2, The runtime service GetNextVariableName interface conformance -1.1 fwts tests INFO passed. -1.1 fwts Test INFO 3 of 9: Test UEFI RT service set variable interface. -1.1 fwts Testing INFO SetVariable on two different GUIDs and the same variable name. -1.1 fwts PASSED: INFO Test 3, SetVariable on two different GUIDs and the same variable name -1.1 fwts passed. INFO passed. -1.1 fwts Testing INFO SetVariable on the same and different variable data. -1.1 fwts PASSED: INFO Test 3, SetVariable on the same and different variable data passed. -1.1 fwts Testing INFO SetVariable on similar variable name. -1.1 fwts PASSED: INFO Test 3, SetVariable on similar variable name passed. -1.1 fwts Testing INFO SetVariable on DataSize is 0. -1.1 fwts PASSED: INFO Test 3, SetVariable on DataSize is 0 passed. -1.1 fwts Testing INFO SetVariable on Attributes is 0. -1.1 fwts PASSED: INFO Test 3, SetVariable on Attributes is 0 passed. -1.1 fwts Testing INFO SetVariable on Invalid Attributes. -1.1 fwts PASSED: INFO Test 3, SetVariable on Invalid Attributes passed. -1.1 fwts Testing INFO SetVariable with both Authenticated Attributes set. -1.1 fwts PASSED: INFO Test 3, Testing SetVariable with both Authenticated Attributes set -1.1 fwts passed. INFO passed. -1.1 fwts Testing INFO SetVariable with EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS Attributes. -1.1 fwts WARNING: INFO Test 3, EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS is deprecated (UEFI -1.1 fwts 2.7) INFO and should not be used. Platforms should return EFI_UNSUPPORTED if a caller -1.1 fwts to INFO SetVariable() specifies this attribute. -1.1 fwts Return INFO status: EFI_INVALID_PARAMETER. A parameter was incorrect. -1.1 fwts Test INFO 4 of 9: Test UEFI RT service query variable info interface. -1.1 fwts PASSED: INFO Test 4, UEFI runtime service query variable info interface test passed. -1.1 fwts Test INFO 5 of 9: Test UEFI RT service variable interface stress test. -1.1 fwts Testing INFO GetVariable on getting the variable 1024 times. -1.1 fwts PASSED: INFO Test 5, GetVariable on getting the variable multiple times passed. -1.1 fwts Testing INFO GetNextVariableName on getting the variable multiple times. -1.1 fwts PASSED: INFO Test 5, GetNextVariableName on getting the next variable name multiple -1.1 fwts times INFO passed. -1.1 fwts Test INFO 6 of 9: Test UEFI RT service set variable interface stress test. -1.1 fwts Testing INFO SetVariable on setting the variable with the same data 40 times. -1.1 fwts PASSED: INFO Test 6, SetVariable on setting the variable with the same data multiple -1.1 fwts times INFO passed. -1.1 fwts Testing INFO SetVariable on setting the variable with different data 40 times. -1.1 fwts PASSED: INFO Test 6, Testing SetVariable on setting the variable with different data -1.1 fwts multiple INFO times passed. -1.1 fwts Testing INFO SetVariable on setting the variable with different name 40 times. -1.1 fwts PASSED: INFO Test 6, Testing SetVariable on setting the variable with different name -1.1 fwts multiple INFO times passed. -1.1 fwts Testing INFO SetVariable on setting the variable with different name and data 40 -1.1 fwts times. INFO times. -1.1 fwts PASSED: INFO Test 6, Testing SetVariable on setting the variable with different name -1.1 fwts and INFO data multiple times passed. -1.1 fwts Test INFO 7 of 9: Test UEFI RT service query variable info interface stress test. -1.1 fwts Testing INFO QueryVariableInfo on querying the variable 1024 times. -1.1 fwts PASSED: INFO Test 7, UEFI runtime service query variable info interface stress test -1.1 fwts passed. INFO passed. -1.1 fwts Test INFO 8 of 9: Test UEFI RT service get variable interface, invalid parameters. -1.1 fwts Testing INFO GetVariable with NULL variable name. -1.1 fwts PASSED: INFO Test 8, GetVariable with NULL variable name returned error -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Testing INFO GetVariable with NULL vendor GUID. -1.1 fwts PASSED: INFO Test 8, GetVariable with NULL vendor GUID returned error -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Testing INFO GetVariable with NULL datasize. -1.1 fwts PASSED: INFO Test 8, GetVariable with NULL datasize returned error -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Testing INFO GetVariable with NULL data. -1.1 fwts PASSED: INFO Test 8, GetVariable with NULL data returned error EFI_INVALID_PARAMETER -1.1 fwts as INFO expected. -1.1 fwts Testing INFO GetVariable with NULL variable name, vendor GUID, datasize and data. -1.1 fwts PASSED: INFO Test 8, GetVariable with NULL variable name, vendor GUID, datasize and -1.1 fwts data INFO returned error EFI_INVALID_PARAMETER as expected. -1.1 fwts Test INFO 9 of 9: Test UEFI RT variable services supported status. -1.1 fwts SKIPPED: INFO Test 9, Cannot get the RuntimeServicesSupported variable, maybe the -1.1 fwts runtime INFO service GetVariable is not supported or RuntimeServicesSupported not -1.1 fwts provided INFO by firmware. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 25 INFO passed, 0 failed, 1 warning, 0 aborted, 1 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts uefirttime: INFO UEFI Runtime service time interface tests. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 36: Test UEFI RT service get time interface. -1.1 fwts PASSED: INFO Test 1, UEFI runtime service GetTime interface test passed. -1.1 fwts Test INFO 2 of 36: Test UEFI RT service get time interface, NULL time parameter. -1.1 fwts PASSED: INFO Test 2, UEFI runtime service GetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 3 of 36: Test UEFI RT service get time interface, NULL time and NULL -1.1 fwts capabilties INFO parameters. -1.1 fwts PASSED: INFO Test 3, UEFI runtime service GetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 4 of 36: Test UEFI RT service set time interface. -1.1 fwts PASSED: INFO Test 4, UEFI runtime service SetTime interface test passed. -1.1 fwts Test INFO 5 of 36: Test UEFI RT service set time interface, invalid year 1899. -1.1 fwts PASSED: INFO Test 5, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 6 of 36: Test UEFI RT service set time interface, invalid year 10000. -1.1 fwts PASSED: INFO Test 6, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 7 of 36: Test UEFI RT service set time interface, invalid month 0. -1.1 fwts PASSED: INFO Test 7, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 8 of 36: Test UEFI RT service set time interface, invalid month 13. -1.1 fwts PASSED: INFO Test 8, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 9 of 36: Test UEFI RT service set time interface, invalid day 0. -1.1 fwts PASSED: INFO Test 9, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 10 of 36: Test UEFI RT service set time interface, invalid day 32. -1.1 fwts PASSED: INFO Test 10, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 11 of 36: Test UEFI RT service set time interface, invalid hour 24. -1.1 fwts PASSED: INFO Test 11, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 12 of 36: Test UEFI RT service set time interface, invalid minute 60. -1.1 fwts PASSED: INFO Test 12, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 13 of 36: Test UEFI RT service set time interface, invalid second 60. -1.1 fwts PASSED: INFO Test 13, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 14 of 36: Test UEFI RT service set time interface, invalid nanosecond -1.1 fwts 1000000000. INFO 1000000000. -1.1 fwts PASSED: INFO Test 14, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 15 of 36: Test UEFI RT service set time interface, invalid timezone -1441. -1.1 fwts PASSED: INFO Test 15, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 16 of 36: Test UEFI RT service set time interface, invalid timezone 1441. -1.1 fwts PASSED: INFO Test 16, UEFI runtime service SetTime interface test passed, returned -1.1 fwts EFI_INVALID_PARAMETER INFO as expected. -1.1 fwts Test INFO 17 of 36: Test UEFI RT service get wakeup time interface. -1.1 fwts SKIPPED: INFO Test 17, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 18 of 36: Test UEFI RT service get wakeup time interface, NULL enabled -1.1 fwts parameter. INFO parameter. -1.1 fwts SKIPPED: INFO Test 18, Skipping test, GetTimeWakeupTime runtime service is not -1.1 fwts supported INFO on this platform. -1.1 fwts Test INFO 19 of 36: Test UEFI RT service get wakeup time interface, NULL pending -1.1 fwts parameter. INFO parameter. -1.1 fwts SKIPPED: INFO Test 19, Skipping test, GetTimeWakeupTime runtime service is not -1.1 fwts supported INFO on this platform. -1.1 fwts Test INFO 20 of 36: Test UEFI RT service get wakeup time interface, NULL time -1.1 fwts parameter. INFO parameter. -1.1 fwts SKIPPED: INFO Test 20, Skipping test, GetTimeWakeupTime runtime service is not -1.1 fwts supported INFO on this platform. -1.1 fwts Test INFO 21 of 36: Test UEFI RT service get wakeup time interface, NULL enabled, -1.1 fwts pending INFO and time parameters. -1.1 fwts SKIPPED: INFO Test 21, Skipping test, GetTimeWakeupTime runtime service is not -1.1 fwts supported INFO on this platform. -1.1 fwts Test INFO 22 of 36: Test UEFI RT service set wakeup time interface. -1.1 fwts SKIPPED: INFO Test 22, Skipping test, SetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 23 of 36: Test UEFI RT service set wakeup time interface, NULL time -1.1 fwts parameter. INFO parameter. -1.1 fwts SKIPPED: INFO Test 23, Skipping test, SetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 24 of 36: Test UEFI RT service set wakeup time interface, invalid year -1.1 fwts 1899. INFO 1899. -1.1 fwts SKIPPED: INFO Test 24, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 25 of 36: Test UEFI RT service set wakeup time interface, invalid year -1.1 fwts 10000. INFO 10000. -1.1 fwts SKIPPED: INFO Test 25, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 26 of 36: Test UEFI RT service set wakeup time interface, invalid month 0. -1.1 fwts SKIPPED: INFO Test 26, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 27 of 36: Test UEFI RT service set wakeup time interface, invalid month 13. -1.1 fwts SKIPPED: INFO Test 27, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 28 of 36: Test UEFI RT service set wakeup time interface, invalid day 0. -1.1 fwts SKIPPED: INFO Test 28, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 29 of 36: Test UEFI RT service set wakeup time interface, invalid day 32. -1.1 fwts SKIPPED: INFO Test 29, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 30 of 36: Test UEFI RT service set wakeup time interface, invalid hour 24. -1.1 fwts SKIPPED: INFO Test 30, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 31 of 36: Test UEFI RT service set wakeup time interface, invalid minute -1.1 fwts 60. INFO 60. -1.1 fwts SKIPPED: INFO Test 31, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 32 of 36: Test UEFI RT service set wakeup time interface, invalid second -1.1 fwts 60. INFO 60. -1.1 fwts SKIPPED: INFO Test 32, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 33 of 36: Test UEFI RT service set wakeup time interface, invalid -1.1 fwts nanosecond INFO 1000000000. -1.1 fwts SKIPPED: INFO Test 33, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 34 of 36: Test UEFI RT service set wakeup time interface, invalid timezone -1.1 fwts -1441. INFO -1441. -1.1 fwts SKIPPED: INFO Test 34, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 35 of 36: Test UEFI RT service set wakeup time interface, invalid timezone -1.1 fwts 1441. INFO 1441. -1.1 fwts SKIPPED: INFO Test 35, Skipping test, GetWakeupTime runtime service is not supported -1.1 fwts on INFO this platform. -1.1 fwts Test INFO 36 of 36: Test UEFI RT time services supported status. -1.1 fwts SKIPPED: INFO Test 36, Cannot get the RuntimeServicesSupported variable, maybe the -1.1 fwts runtime INFO service GetVariable is not supported or RuntimeServicesSupported not -1.1 fwts provided INFO by firmware. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 16 INFO passed, 0 failed, 0 warning, 0 aborted, 20 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts dmicheck: INFO DMI/SMBIOS table tests. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 4: Find and test SMBIOS Table Entry Points. -1.1 fwts This INFO test tries to find and sanity check the SMBIOS data structures. -1.1 fwts Cannot INFO mmap SMBIOS entry at 0x0xfe990000 -1.1 fwts SMBIOS30 INFO entry loaded from /sys/firmware/dmi/tables/smbios_entry_point -1.1 fwts PASSED: INFO Test 1, Found SMBIOS30 Table Entry Point at 0xfe970000 -1.1 fwts SMBIOS30 INFO Entry Point Structure: -1.1 fwts Anchor INFO String : _SM3_ -1.1 fwts Checksum INFO : 0x6a -1.1 fwts Entry INFO Point Length : 0x18 -1.1 fwts Major INFO Version : 0x03 -1.1 fwts Minor INFO Version : 0x03 -1.1 fwts Docrev INFO : 0x00 -1.1 fwts Entry INFO Point Revision : 0x01 -1.1 fwts Reserved INFO : 0x00 -1.1 fwts Table INFO maximum size : 0x0000034f -1.1 fwts Table INFO address : 0x00000000fe960000 -1.1 fwts PASSED: INFO Test 1, SMBIOS30 Table Entry Point Checksum is valid. -1.1 fwts PASSED: INFO Test 1, SMBIOS30 Table Entry Point Length is valid. -1.1 fwts SMBIOS30 INFO table loaded from /sys/firmware/dmi/tables/DMI -1.1 fwts PASSED: INFO Test 1, SMBIOS 3.0 Table Entry Structure Table Address and Length looks -1.1 fwts valid. INFO valid. -1.1 fwts Test INFO 2 of 4: Test DMI/SMBIOS tables for errors. -1.1 fwts SKIPPED: INFO Test 2, This test is not required for SBBR Compliance, skip the test. -1.1 fwts Test INFO 3 of 4: Test DMI/SMBIOS3 tables for errors. -1.1 fwts SMBIOS30 INFO entry loaded from /sys/firmware/dmi/tables/smbios_entry_point -1.1 fwts SMBIOS30 INFO table loaded from /sys/firmware/dmi/tables/DMI -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe960000 'BIOS Information (Type 0)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe960036 'System Information (Type 1)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe9600a0 'Chassis Information (Type 3)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe9600ca 'Processor Information (Type 4)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe960152 'Cache Information (Type 7)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe96018f 'Cache Information (Type 7)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe9601cc 'Cache Information (Type 7)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe960209 'Cache Information (Type 7)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe960246 'Physical Memory Array (Type 16)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe96025f 'Memory Device (Type 17)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe9602bd 'Memory Device (Type 17)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe96031b 'Memory Array Mapped Address (Type 19)' -1.1 fwts PASSED: INFO Test 3, Entry @ 0xfe96033c 'System Boot Information (Type 32)' -1.1 fwts Test INFO 4 of 4: Test ARM SBBR SMBIOS structure requirements. -1.1 fwts PASSED: INFO Test 4, SMBIOS structure BIOS Information (Type 0) found. -1.1 fwts PASSED: INFO Test 4, SMBIOS structure System Information (Type 1) found. -1.1 fwts SKIPPED: INFO Test 4, SMBIOS structure Baseboard Information (Type 2) not found. This -1.1 fwts structure INFO is recommended. -1.1 fwts PASSED: INFO Test 4, SMBIOS structure System Enclosure or Chassis (Type 3) found. -1.1 fwts PASSED: INFO Test 4, SMBIOS structure Processor Information (Type 4) found. -1.1 fwts PASSED: INFO Test 4, SMBIOS structure Cache Information (Type 7) found. -1.1 fwts SKIPPED: INFO Test 4, SMBIOS structure Port Connector Information (Type 8) not found. -1.1 fwts Recommended INFO for platforms with physical ports. -1.1 fwts SKIPPED: INFO Test 4, SMBIOS structure System Slots (Type 9) not found. Required for -1.1 fwts platforms INFO with expansion slots. -1.1 fwts SKIPPED: INFO Test 4, SMBIOS structure OEM Strings (Type 11) not found. This -1.1 fwts structure INFO is recommended. -1.1 fwts SKIPPED: INFO Test 4, SMBIOS structure BIOS Language Information (Type 13) not found. -1.1 fwts This INFO structure is recommended. -1.1 fwts SKIPPED: INFO Test 4, SMBIOS structure System Event Log (Type 15) not found. This -1.1 fwts structure INFO is recommended. -1.1 fwts PASSED: INFO Test 4, SMBIOS structure Physical Memory Array (Type 16) found. -1.1 fwts PASSED: INFO Test 4, SMBIOS structure Memory Device (Type 17) found. -1.1 fwts PASSED: INFO Test 4, SMBIOS structure Memory Array Mapped Address (Type 19) found. -1.1 fwts PASSED: INFO Test 4, SMBIOS structure System Boot Information (Type 32) found. -1.1 fwts SKIPPED: INFO Test 4, SMBIOS structure IPMI Device Information (Type 38) not found. -1.1 fwts Required INFO for platforms with IPMIv1.0 BMC Interface. -1.1 fwts SKIPPED: INFO Test 4, SMBIOS structure Onboard Devices Extended Information (Type 41) -1.1 fwts not INFO found. This structure is recommended. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 26 INFO passed, 0 failed, 0 warning, 0 aborted, 9 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts xsdt: INFO XSDT Extended System Description Table test. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 1: XSDT Extended System Description Table test. -1.1 fwts PASSED: INFO Test 1, XSDT is present, pointed at by XsdrAddress=0xbff00000 and -1.1 fwts contain INFO valid pointers to 15 other ACPI tables mandated by SBBR -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 1 INFO passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts spcr: INFO SPCR Serial Port Console Redirection Table test. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 3: SPCR Serial Port Console Redirection Table test. -1.1 fwts Serial INFO Interface: ARM PL011 UART -1.1 fwts Baud INFO Rate: 115200 -1.1 fwts Terminal INFO Type: ANSI -1.1 fwts PASSED: INFO Test 1, No issues found in SPCR table. -1.1 fwts Test INFO 2 of 3: SPCR Revision Test. -1.1 fwts PASSED: INFO Test 2, SPCR revision is up to date. -1.1 fwts Test INFO 3 of 3: SPCR GSIV Interrupt Test. -1.1 fwts PASSED: INFO Test 3, SPCR appears to be populated with correct GSIV interruptrouting -1.1 fwts information INFO formation for ARM PL011 UART Device -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 3 INFO passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts rsdp_sbbr: INFO SBBR RSDP Root System Description Pointer tests. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 1: RSDP Root System Description Pointer test. -1.1 fwts RSDP INFO Signature = RSD PTR -1.1 fwts RSDP INFO Checksum = 0x0 -1.1 fwts RSDP INFO Revision = 0x2 -1.1 fwts RSDP INFO Length = 0x24 -1.1 fwts RSDP INFO Extended Checksum = 0x0 -1.1 fwts PASSED: INFO Test 1, SBBR RSDP: Structure of RSDP Table is consistent with ACPI 6.0 -1.1 fwts or INFO later and uses 64 bit xsdt addresses. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 1 INFO passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts method: INFO ACPI DSDT Method Semantic tests. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts FADT INFO Preferred PM profile indicates this is not a Mobile Platform. -1.1 fwts Test INFO 1 of 203: Test Method Names. -1.1 fwts Found INFO 138 Objects -1.1 fwts PASSED: INFO Test 1, Method names contain legal characters. -1.1 fwts Test INFO 2 of 203: Test _AEI. -1.1 fwts PASSED: INFO Test 2, \_SB_.GPI0._AEI correctly returned a sane looking buffer. -1.1 fwts Test INFO 3 of 203: Test _EVT (Event Method). -1.1 fwts Failed INFO to find valid handle for _EVT method (0x5), \_SB.GPI0._EVT -1.1 fwts Test INFO 4 of 203: Test _DLM (Device Lock Mutex). -1.1 fwts SKIPPED: INFO Test 4, Skipping test for non-existent object _DLM. -1.1 fwts Test INFO 5 of 203: Test _PIC (Inform AML of Interrupt Model). -1.1 fwts SKIPPED: INFO Test 5, Skipping test for non-existent object _PIC. -1.1 fwts Test INFO 6 of 203: Test _CID (Compatible ID). -1.1 fwts PASSED: INFO Test 6, \_SB_.PCI0._CID returned an integer 0x030ad041 (EISA ID -1.1 fwts PNP0A03). INFO PNP0A03). -1.1 fwts PASSED: INFO Test 6, \_SB_.COM0._CID returned a string 'ARMH0011' as expected. -1.1 fwts Test INFO 7 of 203: Test _CLS (Class Code). -1.1 fwts WARNING: INFO Test 7, -1.1 fwts SKIPPED: INFO Test 7, Skipping test for non-existent object _CLS. -1.1 fwts Test INFO 8 of 203: Test _DDN (DOS Device Name). -1.1 fwts SKIPPED: INFO Test 8, Skipping test for non-existent object _DDN. -1.1 fwts Test INFO 9 of 203: Test _HID (Hardware ID). -1.1 fwts PASSED: INFO Test 9, \_SB_.SPKG._HID returned a string 'ACPI0010' as expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.SPKG.CLU0._HID returned a string 'ACPI0010' as expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.SPKG.CLU0.CP00._HID returned a string 'ACPI0007' as -1.1 fwts expected. INFO expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.SPKG.CLU0.CP01._HID returned a string 'ACPI0007' as -1.1 fwts expected. INFO expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.SPKG.CLU0.CP02._HID returned a string 'ACPI0007' as -1.1 fwts expected. INFO expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.SPKG.CLU0.CP03._HID returned a string 'ACPI0007' as -1.1 fwts expected. INFO expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.SPKG.CLU1._HID returned a string 'ACPI0010' as expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.SPKG.CLU1.CP04._HID returned a string 'ACPI0007' as -1.1 fwts expected. INFO expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.SPKG.CLU1.CP05._HID returned a string 'ACPI0007' as -1.1 fwts expected. INFO expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.SPKG.CLU1.CP06._HID returned a string 'ACPI0007' as -1.1 fwts expected. INFO expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.SPKG.CLU1.CP07._HID returned a string 'ACPI0007' as -1.1 fwts expected. INFO expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.LNKA._HID returned an integer 0x0f0cd041 (EISA ID -1.1 fwts PNP0C0F). INFO PNP0C0F). -1.1 fwts PASSED: INFO Test 9, \_SB_.LNKB._HID returned an integer 0x0f0cd041 (EISA ID -1.1 fwts PNP0C0F). INFO PNP0C0F). -1.1 fwts PASSED: INFO Test 9, \_SB_.LNKC._HID returned an integer 0x0f0cd041 (EISA ID -1.1 fwts PNP0C0F). INFO PNP0C0F). -1.1 fwts PASSED: INFO Test 9, \_SB_.LNKD._HID returned an integer 0x0f0cd041 (EISA ID -1.1 fwts PNP0C0F). INFO PNP0C0F). -1.1 fwts PASSED: INFO Test 9, \_SB_.PCI0._HID returned an integer 0x080ad041 (EISA ID -1.1 fwts PNP0A08). INFO PNP0A08). -1.1 fwts PASSED: INFO Test 9, \_SB_.GED0._HID returned a string 'ACPI0013' as expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.GPI0._HID returned a string 'ARMH0061' as expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.COM0._HID returned a string 'ARMH0011' as expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.ETH0._HID returned a string 'LNRO0003' as expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.VR00._HID returned a string 'LNRO0005' as expected. -1.1 fwts PASSED: INFO Test 9, \_SB_.VR01._HID returned a string 'LNRO0005' as expected. -1.1 fwts Test INFO 10 of 203: Test _HRV (Hardware Revision Number). -1.1 fwts SKIPPED: INFO Test 10, Skipping test for non-existent object _HRV. -1.1 fwts Test INFO 11 of 203: Test _MLS (Multiple Language String). -1.1 fwts SKIPPED: INFO Test 11, Skipping test for non-existent object _MLS. -1.1 fwts Test INFO 12 of 203: Test _PLD (Physical Device Location). -1.1 fwts SKIPPED: INFO Test 12, Skipping test for non-existent object _PLD. -1.1 fwts Test INFO 13 of 203: Test _SUB (Subsystem ID). -1.1 fwts SKIPPED: INFO Test 13, Skipping test for non-existent object _SUB. -1.1 fwts Test INFO 14 of 203: Test _SUN (Slot User Number). -1.1 fwts SKIPPED: INFO Test 14, Skipping test for non-existent object _SUN. -1.1 fwts Test INFO 15 of 203: Test _STR (String). -1.1 fwts SKIPPED: INFO Test 15, Skipping test for non-existent object _STR. -1.1 fwts Test INFO 16 of 203: Test _UID (Unique ID). -1.1 fwts PASSED: INFO Test 16, \_SB_.SPKG._UID correctly returned sane looking value -1.1 fwts 0x00000000. INFO 0x00000000. -1.1 fwts PASSED: INFO Test 16, \_SB_.SPKG.CLU0._UID correctly returned sane looking value -1.1 fwts 0x00000001. INFO 0x00000001. -1.1 fwts PASSED: INFO Test 16, \_SB_.SPKG.CLU0.CP00._UID correctly returned sane looking value -1.1 fwts 0x00000000. INFO 0x00000000. -1.1 fwts PASSED: INFO Test 16, \_SB_.SPKG.CLU0.CP01._UID correctly returned sane looking value -1.1 fwts 0x00000001. INFO 0x00000001. -1.1 fwts PASSED: INFO Test 16, \_SB_.SPKG.CLU0.CP02._UID correctly returned sane looking value -1.1 fwts 0x00000002. INFO 0x00000002. -1.1 fwts PASSED: INFO Test 16, \_SB_.SPKG.CLU0.CP03._UID correctly returned sane looking value -1.1 fwts 0x00000003. INFO 0x00000003. -1.1 fwts PASSED: INFO Test 16, \_SB_.SPKG.CLU1._UID correctly returned sane looking value -1.1 fwts 0x00000002. INFO 0x00000002. -1.1 fwts PASSED: INFO Test 16, \_SB_.SPKG.CLU1.CP04._UID correctly returned sane looking value -1.1 fwts 0x00000004. INFO 0x00000004. -1.1 fwts PASSED: INFO Test 16, \_SB_.SPKG.CLU1.CP05._UID correctly returned sane looking value -1.1 fwts 0x00000005. INFO 0x00000005. -1.1 fwts PASSED: INFO Test 16, \_SB_.SPKG.CLU1.CP06._UID correctly returned sane looking value -1.1 fwts 0x00000006. INFO 0x00000006. -1.1 fwts PASSED: INFO Test 16, \_SB_.SPKG.CLU1.CP07._UID correctly returned sane looking value -1.1 fwts 0x00000007. INFO 0x00000007. -1.1 fwts PASSED: INFO Test 16, \_SB_.LNKA._UID correctly returned sane looking value -1.1 fwts 0x00000000. INFO 0x00000000. -1.1 fwts PASSED: INFO Test 16, \_SB_.LNKB._UID correctly returned sane looking value -1.1 fwts 0x00000001. INFO 0x00000001. -1.1 fwts PASSED: INFO Test 16, \_SB_.LNKC._UID correctly returned sane looking value -1.1 fwts 0x00000002. INFO 0x00000002. -1.1 fwts PASSED: INFO Test 16, \_SB_.LNKD._UID correctly returned sane looking value -1.1 fwts 0x00000003. INFO 0x00000003. -1.1 fwts PASSED: INFO Test 16, \_SB_.GED0._UID correctly returned sane looking value -1.1 fwts 0x00000000. INFO 0x00000000. -1.1 fwts PASSED: INFO Test 16, \_SB_.GPI0._UID correctly returned sane looking value -1.1 fwts 0x00000000. INFO 0x00000000. -1.1 fwts PASSED: INFO Test 16, \_SB_.COM0._UID correctly returned sane looking value -1.1 fwts 0x00000000. INFO 0x00000000. -1.1 fwts PASSED: INFO Test 16, \_SB_.ETH0._UID correctly returned sane looking value -1.1 fwts 0x00000000. INFO 0x00000000. -1.1 fwts PASSED: INFO Test 16, \_SB_.VR00._UID correctly returned sane looking value -1.1 fwts 0x00000000. INFO 0x00000000. -1.1 fwts PASSED: INFO Test 16, \_SB_.VR01._UID correctly returned sane looking value -1.1 fwts 0x00000001. INFO 0x00000001. -1.1 fwts Test INFO 17 of 203: Test _CDM (Clock Domain). -1.1 fwts SKIPPED: INFO Test 17, Skipping test for non-existent object _CDM. -1.1 fwts Test INFO 18 of 203: Test _CRS (Current Resource Settings). -1.1 fwts PASSED: INFO Test 18, \_SB_.LNKA._CRS (Extended IRQ Descriptor) looks sane. -1.1 fwts PASSED: INFO Test 18, \_SB_.LNKB._CRS (Extended IRQ Descriptor) looks sane. -1.1 fwts PASSED: INFO Test 18, \_SB_.LNKC._CRS (Extended IRQ Descriptor) looks sane. -1.1 fwts PASSED: INFO Test 18, \_SB_.LNKD._CRS (Extended IRQ Descriptor) looks sane. -1.1 fwts PASSED: INFO Test 18, \_SB_.PCI0._CRS (WORD Address Space Descriptor) looks sane. -1.1 fwts PASSED: INFO Test 18, \_SB_.GED0._CRS (Extended IRQ Descriptor) looks sane. -1.1 fwts PASSED: INFO Test 18, \_SB_.GPI0._CRS (32-bit Fixed Location Memory Range Descriptor) -1.1 fwts looks INFO sane. -1.1 fwts PASSED: INFO Test 18, \_SB_.COM0._CRS (32-bit Fixed Location Memory Range Descriptor) -1.1 fwts looks INFO sane. -1.1 fwts PASSED: INFO Test 18, \_SB_.ETH0._CRS (32-bit Fixed Location Memory Range Descriptor) -1.1 fwts looks INFO sane. -1.1 fwts PASSED: INFO Test 18, \_SB_.VR00._CRS (32-bit Fixed Location Memory Range Descriptor) -1.1 fwts looks INFO sane. -1.1 fwts PASSED: INFO Test 18, \_SB_.VR01._CRS (32-bit Fixed Location Memory Range Descriptor) -1.1 fwts looks INFO sane. -1.1 fwts Test INFO 19 of 203: Test _DSD (Device Specific Data). -1.1 fwts Test INFO 20 of 203: Test _DIS (Disable). -1.1 fwts PASSED: INFO Test 20, \_SB_.LNKA._DIS returned no values as expected. -1.1 fwts PASSED: INFO Test 20, \_SB_.LNKB._DIS returned no values as expected. -1.1 fwts PASSED: INFO Test 20, \_SB_.LNKC._DIS returned no values as expected. -1.1 fwts PASSED: INFO Test 20, \_SB_.LNKD._DIS returned no values as expected. -1.1 fwts Test INFO 21 of 203: Test _DMA (Direct Memory Access). -1.1 fwts SKIPPED: INFO Test 21, Skipping test for non-existent object _DMA. -1.1 fwts Test INFO 22 of 203: Test _FIX (Fixed Register Resource Provider). -1.1 fwts SKIPPED: INFO Test 22, Skipping test for non-existent object _FIX. -1.1 fwts Test INFO 23 of 203: Test _GSB (Global System Interrupt Base). -1.1 fwts SKIPPED: INFO Test 23, Skipping test for non-existent object _GSB. -1.1 fwts Test INFO 24 of 203: Test _HPP (Hot Plug Parameters). -1.1 fwts WARNING: INFO Test 24, -1.1 fwts SKIPPED: INFO Test 24, Skipping test for non-existent object _HPP. -1.1 fwts Test INFO 25 of 203: Test _MAT (Multiple APIC Table Entry). -1.1 fwts SKIPPED: INFO Test 25, Skipping test for non-existent object _MAT. -1.1 fwts Test INFO 26 of 203: Test _PRS (Possible Resource Settings). -1.1 fwts PASSED: INFO Test 26, \_SB_.LNKA._PRS (Extended IRQ Descriptor) looks sane. -1.1 fwts PASSED: INFO Test 26, \_SB_.LNKB._PRS (Extended IRQ Descriptor) looks sane. -1.1 fwts PASSED: INFO Test 26, \_SB_.LNKC._PRS (Extended IRQ Descriptor) looks sane. -1.1 fwts PASSED: INFO Test 26, \_SB_.LNKD._PRS (Extended IRQ Descriptor) looks sane. -1.1 fwts Test INFO 27 of 203: Test _PRT (PCI Routing Table). -1.1 fwts PASSED: INFO Test 27, \_SB_.PCI0._PRT correctly returned a sane looking package. -1.1 fwts Test INFO 28 of 203: Test _PXM (Proximity). -1.1 fwts SKIPPED: INFO Test 28, Skipping test for non-existent object _PXM. -1.1 fwts Test INFO 29 of 203: Test _SLI (System Locality Information). -1.1 fwts WARNING: INFO Test 29, _SLI method not found. Recommended for NUMA systems to -1.1 fwts dynamically INFO update SLIT. -1.1 fwts SKIPPED: INFO Test 29, Skipping test for non-existent object _SLI. -1.1 fwts Test INFO 30 of 203: Test _CCA (Cache Coherency Attribute). -1.1 fwts PASSED: INFO Test 30, \_SB_.PCI0._CCA correctly returned sane looking value -1.1 fwts 0x00000001. INFO 0x00000001. -1.1 fwts PASSED: INFO Test 30, \_SB_.VR00._CCA correctly returned sane looking value -1.1 fwts 0x00000001. INFO 0x00000001. -1.1 fwts PASSED: INFO Test 30, \_SB_.VR01._CCA correctly returned sane looking value -1.1 fwts 0x00000001. INFO 0x00000001. -1.1 fwts Test INFO 31 of 203: Test _HMA (Heterogeneous Memory Attributes). -1.1 fwts WARNING: INFO Test 31, _HMA method not found. Recommended for NUMA systems to -1.1 fwts dynamically INFO update HMAT. -1.1 fwts SKIPPED: INFO Test 31, Skipping test for non-existent object _HMA. -1.1 fwts Test INFO 32 of 203: Test _EDL (Eject Device List). -1.1 fwts WARNING: INFO Test 32, _EDL -1.1 fwts SKIPPED: INFO Test 32, Skipping test for non-existent object _EDL. -1.1 fwts Test INFO 33 of 203: Test _EJD (Ejection Dependent Device). -1.1 fwts SKIPPED: INFO Test 33, Skipping test for non-existent object _EJD. -1.1 fwts Test INFO 34 of 203: Test _EJ0 (Eject). -1.1 fwts WARNING: INFO Test 34, _EJ0 -1.1 fwts SKIPPED: INFO Test 34, Skipping test for non-existent object _EJ0. -1.1 fwts Test INFO 35 of 203: Test _EJ1 (Eject). -1.1 fwts WARNING: INFO Test 35, _EJ1 -1.1 fwts SKIPPED: INFO Test 35, Skipping test for non-existent object _EJ1. -1.1 fwts Test INFO 36 of 203: Test _EJ2 (Eject). -1.1 fwts WARNING: INFO Test 36, _EJ2 -1.1 fwts SKIPPED: INFO Test 36, Skipping test for non-existent object _EJ2. -1.1 fwts Test INFO 37 of 203: Test _EJ3 (Eject). -1.1 fwts WARNING: INFO Test 37, _EJ3 -1.1 fwts SKIPPED: INFO Test 37, Skipping test for non-existent object _EJ3. -1.1 fwts Test INFO 38 of 203: Test _EJ4 (Eject). -1.1 fwts WARNING: INFO Test 38, _EJ4 -1.1 fwts SKIPPED: INFO Test 38, Skipping test for non-existent object _EJ4. -1.1 fwts Test INFO 39 of 203: Test _LCK (Lock). -1.1 fwts SKIPPED: INFO Test 39, Skipping test for non-existent object _LCK. -1.1 fwts Test INFO 40 of 203: Test _RMV (Remove). -1.1 fwts WARNING: INFO Test 40, _RMV -1.1 fwts SKIPPED: INFO Test 40, Skipping test for non-existent object _RMV. -1.1 fwts Test INFO 41 of 203: Test _STA (Status). -1.1 fwts PASSED: INFO Test 41, \_SB_.SPKG.CLU0.CP00._STA correctly returned sane looking value -1.1 fwts 0x0000000f. INFO 0x0000000f. -1.1 fwts PASSED: INFO Test 41, \_SB_.SPKG.CLU0.CP01._STA correctly returned sane looking value -1.1 fwts 0x0000000f. INFO 0x0000000f. -1.1 fwts PASSED: INFO Test 41, \_SB_.SPKG.CLU0.CP02._STA correctly returned sane looking value -1.1 fwts 0x0000000f. INFO 0x0000000f. -1.1 fwts PASSED: INFO Test 41, \_SB_.SPKG.CLU0.CP03._STA correctly returned sane looking value -1.1 fwts 0x0000000f. INFO 0x0000000f. -1.1 fwts PASSED: INFO Test 41, \_SB_.SPKG.CLU1.CP04._STA correctly returned sane looking value -1.1 fwts 0x0000000f. INFO 0x0000000f. -1.1 fwts PASSED: INFO Test 41, \_SB_.SPKG.CLU1.CP05._STA correctly returned sane looking value -1.1 fwts 0x0000000f. INFO 0x0000000f. -1.1 fwts PASSED: INFO Test 41, \_SB_.SPKG.CLU1.CP06._STA correctly returned sane looking value -1.1 fwts 0x0000000f. INFO 0x0000000f. -1.1 fwts PASSED: INFO Test 41, \_SB_.SPKG.CLU1.CP07._STA correctly returned sane looking value -1.1 fwts 0x0000000f. INFO 0x0000000f. -1.1 fwts PASSED: INFO Test 41, \_SB_.GED0._STA correctly returned sane looking value -1.1 fwts 0x0000000f. INFO 0x0000000f. -1.1 fwts PASSED: INFO Test 41, \_SB_.COM0._STA correctly returned sane looking value -1.1 fwts 0x0000000f. INFO 0x0000000f. -1.1 fwts PASSED: INFO Test 41, \_SB_.ETH0._STA correctly returned sane looking value -1.1 fwts 0x0000000f. INFO 0x0000000f. -1.1 fwts Test INFO 42 of 203: Test _DEP (Operational Region Dependencies). -1.1 fwts WARNING: INFO Test 42, _DEP -1.1 fwts SKIPPED: INFO Test 42, Skipping test for non-existent object _DEP. -1.1 fwts Test INFO 43 of 203: Test _FIT (Firmware Interface Table). -1.1 fwts SKIPPED: INFO Test 43, Skipping test for non-existent object _FIT. -1.1 fwts Test INFO 44 of 203: Test _BDN (BIOS Dock Name). -1.1 fwts WARNING: INFO Test 44, _BDN -1.1 fwts SKIPPED: INFO Test 44, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _BDN. -1.1 fwts Test INFO 45 of 203: Test _BBN (Base Bus Number). -1.1 fwts PASSED: INFO Test 45, \_SB_.PCI0._BBN correctly returned an integer. -1.1 fwts Test INFO 46 of 203: Test _DCK (Dock). -1.1 fwts WARNING: INFO Test 46, _DCK -1.1 fwts SKIPPED: INFO Test 46, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _DCK. -1.1 fwts Test INFO 47 of 203: Test _INI (Initialize). -1.1 fwts SKIPPED: INFO Test 47, Skipping test for non-existent object _INI. -1.1 fwts Test INFO 48 of 203: Test _GLK (Global Lock). -1.1 fwts WARNING: INFO Test 48, _GLK -1.1 fwts SKIPPED: INFO Test 48, Skipping test for non-existent object _GLK. -1.1 fwts Test INFO 49 of 203: Test _SEG (Segment). -1.1 fwts PASSED: INFO Test 49, \_SB_.PCI0._SEG correctly returned an integer. -1.1 fwts Test INFO 50 of 203: Test _LSI (Label Storage Information). -1.1 fwts WARNING: INFO Test 50, -1.1 fwts SKIPPED: INFO Test 50, Skipping test for non-existent object _LSI. -1.1 fwts Test INFO 51 of 203: Test _OFF (Set resource off). -1.1 fwts SKIPPED: INFO Test 51, Skipping test for non-existent object _OFF. -1.1 fwts Test INFO 52 of 203: Test _ON_ (Set resource on). -1.1 fwts SKIPPED: INFO Test 52, Skipping test for non-existent object _ON_. -1.1 fwts Test INFO 53 of 203: Test _DSW (Device Sleep Wake). -1.1 fwts SKIPPED: INFO Test 53, Skipping test for non-existent object _DSW. -1.1 fwts Test INFO 54 of 203: Test _IRC (In Rush Current). -1.1 fwts SKIPPED: INFO Test 54, Skipping test for non-existent object _IRC. -1.1 fwts Test INFO 55 of 203: Test _PRE (Power Resources for Enumeration). -1.1 fwts WARNING: INFO Test 55, _PRE -1.1 fwts SKIPPED: INFO Test 55, Skipping test for non-existent object _PRE. -1.1 fwts Test INFO 56 of 203: Test _PR0 (Power Resources for D0). -1.1 fwts WARNING: INFO Test 56, _PR0 -1.1 fwts SKIPPED: INFO Test 56, Skipping test for non-existent object _PR0. -1.1 fwts Test INFO 57 of 203: Test _PR1 (Power Resources for D1). -1.1 fwts WARNING: INFO Test 57, _PR1 -1.1 fwts SKIPPED: INFO Test 57, Skipping test for non-existent object _PR1. -1.1 fwts Test INFO 58 of 203: Test _PR2 (Power Resources for D2). -1.1 fwts WARNING: INFO Test 58, _PR2 -1.1 fwts SKIPPED: INFO Test 58, Skipping test for non-existent object _PR2. -1.1 fwts Test INFO 59 of 203: Test _PR3 (Power Resources for D3). -1.1 fwts WARNING: INFO Test 59, _PR3 -1.1 fwts SKIPPED: INFO Test 59, Skipping test for non-existent object _PR3. -1.1 fwts Test INFO 60 of 203: Test _PRW (Power Resources for Wake). -1.1 fwts SKIPPED: INFO Test 60, Skipping test for non-existent object _PRW. -1.1 fwts Test INFO 61 of 203: Test _PS0 (Power State 0). -1.1 fwts SKIPPED: INFO Test 61, Skipping test for non-existent object _PS0. -1.1 fwts Test INFO 62 of 203: Test _PS1 (Power State 1). -1.1 fwts WARNING: INFO Test 62, _PS1 -1.1 fwts SKIPPED: INFO Test 62, Skipping test for non-existent object _PS1. -1.1 fwts Test INFO 63 of 203: Test _PS2 (Power State 2). -1.1 fwts WARNING: INFO Test 63, _PS2 -1.1 fwts SKIPPED: INFO Test 63, Skipping test for non-existent object _PS2. -1.1 fwts Test INFO 64 of 203: Test _PS3 (Power State 3). -1.1 fwts WARNING: INFO Test 64, _PS3 -1.1 fwts SKIPPED: INFO Test 64, Skipping test for non-existent object _PS3. -1.1 fwts Test INFO 65 of 203: Test _PSC (Power State Current). -1.1 fwts WARNING: INFO Test 65, -1.1 fwts SKIPPED: INFO Test 65, Skipping test for non-existent object _PSC. -1.1 fwts Test INFO 66 of 203: Test _PSE (Power State for Enumeration). -1.1 fwts SKIPPED: INFO Test 66, Skipping test for non-existent object _PSE. -1.1 fwts Test INFO 67 of 203: Test _PSW (Power State Wake). -1.1 fwts SKIPPED: INFO Test 67, Skipping test for non-existent object _PSW. -1.1 fwts Test INFO 68 of 203: Test _S1D (S1 Device State). -1.1 fwts WARNING: INFO Test 68, -1.1 fwts SKIPPED: INFO Test 68, Skipping test for non-existent object _S1D. -1.1 fwts Test INFO 69 of 203: Test _S2D (S2 Device State). -1.1 fwts WARNING: INFO Test 69, -1.1 fwts SKIPPED: INFO Test 69, Skipping test for non-existent object _S2D. -1.1 fwts Test INFO 70 of 203: Test _S3D (S3 Device State). -1.1 fwts WARNING: INFO Test 70, -1.1 fwts SKIPPED: INFO Test 70, Skipping test for non-existent object _S3D. -1.1 fwts Test INFO 71 of 203: Test _S4D (S4 Device State). -1.1 fwts WARNING: INFO Test 71, -1.1 fwts SKIPPED: INFO Test 71, Skipping test for non-existent object _S4D. -1.1 fwts Test INFO 72 of 203: Test _S0W (S0 Device Wake State). -1.1 fwts WARNING: INFO Test 72, -1.1 fwts SKIPPED: INFO Test 72, Skipping test for non-existent object _S0W. -1.1 fwts Test INFO 73 of 203: Test _S1W (S1 Device Wake State). -1.1 fwts WARNING: INFO Test 73, -1.1 fwts SKIPPED: INFO Test 73, Skipping test for non-existent object _S1W. -1.1 fwts Test INFO 74 of 203: Test _S2W (S2 Device Wake State). -1.1 fwts WARNING: INFO Test 74, -1.1 fwts SKIPPED: INFO Test 74, Skipping test for non-existent object _S2W. -1.1 fwts Test INFO 75 of 203: Test _S3W (S3 Device Wake State). -1.1 fwts WARNING: INFO Test 75, -1.1 fwts SKIPPED: INFO Test 75, Skipping test for non-existent object _S3W. -1.1 fwts Test INFO 76 of 203: Test _S4W (S4 Device Wake State). -1.1 fwts WARNING: INFO Test 76, -1.1 fwts SKIPPED: INFO Test 76, Skipping test for non-existent object _S4W. -1.1 fwts Test INFO 77 of 203: Test _RST (Device Reset). -1.1 fwts SKIPPED: INFO Test 77, Skipping test for non-existent object _RST. -1.1 fwts Test INFO 78 of 203: Test _PRR (Power Resource for Reset). -1.1 fwts SKIPPED: INFO Test 78, Skipping test for non-existent object _PRR. -1.1 fwts Test INFO 79 of 203: Test _S0_ (S0 System State). -1.1 fwts WARNING: INFO Test 79, _S0_ -1.1 fwts SKIPPED: INFO Test 79, Skipping test for non-existent object _S0_. -1.1 fwts Test INFO 80 of 203: Test _S1_ (S1 System State). -1.1 fwts WARNING: INFO Test 80, _S1_ -1.1 fwts SKIPPED: INFO Test 80, Skipping test for non-existent object _S1_. -1.1 fwts Test INFO 81 of 203: Test _S2_ (S2 System State). -1.1 fwts WARNING: INFO Test 81, _S2_ -1.1 fwts SKIPPED: INFO Test 81, Skipping test for non-existent object _S2_. -1.1 fwts Test INFO 82 of 203: Test _S3_ (S3 System State). -1.1 fwts WARNING: INFO Test 82, _S3_ -1.1 fwts SKIPPED: INFO Test 82, Skipping test for non-existent object _S3_. -1.1 fwts Test INFO 83 of 203: Test _S4_ (S4 System State). -1.1 fwts WARNING: INFO Test 83, _S4_ -1.1 fwts SKIPPED: INFO Test 83, Skipping test for non-existent object _S4_. -1.1 fwts Test INFO 84 of 203: Test _S5_ (S5 System State). -1.1 fwts WARNING: INFO Test 84, _S5_ -1.1 fwts SKIPPED: INFO Test 84, Skipping test for non-existent object _S5_. -1.1 fwts Test INFO 85 of 203: Test _SWS (System Wake Source). -1.1 fwts SKIPPED: INFO Test 85, Skipping test for non-existent object _SWS. -1.1 fwts Test INFO 86 of 203: Test _PSS (Performance Supported States). -1.1 fwts SKIPPED: INFO Test 86, Skipping test for non-existent object _PSS. -1.1 fwts Test INFO 87 of 203: Test _CPC (Continuous Performance Control). -1.1 fwts SKIPPED: INFO Test 87, Skipping test for non-existent object _CPC. -1.1 fwts Test INFO 88 of 203: Test _CSD (C State Dependencies). -1.1 fwts SKIPPED: INFO Test 88, Skipping test for non-existent object _CSD. -1.1 fwts Test INFO 89 of 203: Test _CST (C States). -1.1 fwts SKIPPED: INFO Test 89, Skipping test for non-existent object _CST. -1.1 fwts Test INFO 90 of 203: Test _PCT (Performance Control). -1.1 fwts SKIPPED: INFO Test 90, Skipping test for non-existent object _PCT. -1.1 fwts Test INFO 91 of 203: Test _PDL (P-State Depth Limit). -1.1 fwts SKIPPED: INFO Test 91, Skipping test for non-existent object _PDL. -1.1 fwts Test INFO 92 of 203: Test _PPC (Performance Present Capabilities). -1.1 fwts SKIPPED: INFO Test 92, Skipping test for non-existent object _PPC. -1.1 fwts Test INFO 93 of 203: Test _PPE (Polling for Platform Error). -1.1 fwts SKIPPED: INFO Test 93, Skipping test for non-existent object _PPE. -1.1 fwts Test INFO 94 of 203: Test _PSD (Power State Dependencies). -1.1 fwts SKIPPED: INFO Test 94, Skipping test for non-existent object _PSD. -1.1 fwts Test INFO 95 of 203: Test _PTC (Processor Throttling Control). -1.1 fwts SKIPPED: INFO Test 95, Skipping test for non-existent object _PTC. -1.1 fwts Test INFO 96 of 203: Test _TDL (T-State Depth Limit). -1.1 fwts SKIPPED: INFO Test 96, Skipping test for non-existent object _TDL. -1.1 fwts Test INFO 97 of 203: Test _TPC (Throttling Present Capabilities). -1.1 fwts SKIPPED: INFO Test 97, Skipping test for non-existent object _TPC. -1.1 fwts Test INFO 98 of 203: Test _TSD (Throttling State Dependencies). -1.1 fwts SKIPPED: INFO Test 98, Skipping test for non-existent object _TSD. -1.1 fwts Test INFO 99 of 203: Test _TSS (Throttling Supported States). -1.1 fwts SKIPPED: INFO Test 99, Skipping test for non-existent object _TSS. -1.1 fwts Test INFO 100 of 203: Test _LPI (Low Power Idle States). -1.1 fwts PASSED: INFO Test 100, \_SB_.SPKG.CLU0._LPI correctly returned a sane looking -1.1 fwts package. INFO package. -1.1 fwts PASSED: INFO Test 100, \_SB_.SPKG.CLU0.CP00._LPI correctly returned a sane looking -1.1 fwts package. INFO package. -1.1 fwts PASSED: INFO Test 100, \_SB_.SPKG.CLU0.CP01._LPI correctly returned a sane looking -1.1 fwts package. INFO package. -1.1 fwts PASSED: INFO Test 100, \_SB_.SPKG.CLU0.CP02._LPI correctly returned a sane looking -1.1 fwts package. INFO package. -1.1 fwts PASSED: INFO Test 100, \_SB_.SPKG.CLU0.CP03._LPI correctly returned a sane looking -1.1 fwts package. INFO package. -1.1 fwts PASSED: INFO Test 100, \_SB_.SPKG.CLU1._LPI correctly returned a sane looking -1.1 fwts package. INFO package. -1.1 fwts PASSED: INFO Test 100, \_SB_.SPKG.CLU1.CP04._LPI correctly returned a sane looking -1.1 fwts package. INFO package. -1.1 fwts PASSED: INFO Test 100, \_SB_.SPKG.CLU1.CP05._LPI correctly returned a sane looking -1.1 fwts package. INFO package. -1.1 fwts PASSED: INFO Test 100, \_SB_.SPKG.CLU1.CP06._LPI correctly returned a sane looking -1.1 fwts package. INFO package. -1.1 fwts PASSED: INFO Test 100, \_SB_.SPKG.CLU1.CP07._LPI correctly returned a sane looking -1.1 fwts package. INFO package. -1.1 fwts Test INFO 101 of 203: Test _RDI (Resource Dependencies for Idle). -1.1 fwts SKIPPED: INFO Test 101, Skipping test for non-existent object _RDI. -1.1 fwts Test INFO 102 of 203: Test _PUR (Processor Utilization Request). -1.1 fwts SKIPPED: INFO Test 102, Skipping test for non-existent object _PUR. -1.1 fwts Test INFO 103 of 203: Test _MSG (Message). -1.1 fwts SKIPPED: INFO Test 103, Skipping test for non-existent object _MSG. -1.1 fwts Test INFO 104 of 203: Test _SST (System Status). -1.1 fwts SKIPPED: INFO Test 104, Skipping test for non-existent object _SST. -1.1 fwts WARNING: INFO Test 104, _SST method not found. This should be treated as error if the -1.1 fwts platform INFO provides user visible status such as LED. -1.1 fwts Test INFO 105 of 203: Test _ALC (Ambient Light Colour Chromaticity). -1.1 fwts WARNING: INFO Test 105, _ALC -1.1 fwts SKIPPED: INFO Test 105, Skipping test for non-existent object _ALC. -1.1 fwts Test INFO 106 of 203: Test _ALI (Ambient Light Illuminance). -1.1 fwts WARNING: INFO Test 106, _ALI -1.1 fwts SKIPPED: INFO Test 106, Skipping test for non-existent object _ALI. -1.1 fwts Test INFO 107 of 203: Test _ALT (Ambient Light Temperature). -1.1 fwts WARNING: INFO Test 107, _ALT -1.1 fwts SKIPPED: INFO Test 107, Skipping test for non-existent object _ALT. -1.1 fwts Test INFO 108 of 203: Test _ALP (Ambient Light Polling). -1.1 fwts WARNING: INFO Test 108, _ALP -1.1 fwts SKIPPED: INFO Test 108, Skipping test for non-existent object _ALP. -1.1 fwts Test INFO 109 of 203: Test _ALR (Ambient Light Response). -1.1 fwts SKIPPED: INFO Test 109, Skipping test for non-existent object _ALR. -1.1 fwts Test INFO 110 of 203: Test _LID (Lid Status). -1.1 fwts SKIPPED: INFO Test 110, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _LID. -1.1 fwts Test INFO 111 of 203: Test _GTF (Get Task File). -1.1 fwts SKIPPED: INFO Test 111, Skipping test for non-existent object _GTF. -1.1 fwts Test INFO 112 of 203: Test _GTM (Get Timing Mode). -1.1 fwts SKIPPED: INFO Test 112, Skipping test for non-existent object _GTM. -1.1 fwts Test INFO 113 of 203: Test _MBM (Memory Bandwidth Monitoring Data). -1.1 fwts WARNING: INFO Test 113, -1.1 fwts SKIPPED: INFO Test 113, Skipping test for non-existent object _MBM. -1.1 fwts Test INFO 114 of 203: Test _UPC (USB Port Capabilities). -1.1 fwts SKIPPED: INFO Test 114, Skipping test for non-existent object _UPC. -1.1 fwts Test INFO 115 of 203: Test _UPD (User Presence Detect). -1.1 fwts SKIPPED: INFO Test 115, Skipping test for non-existent object _UPD. -1.1 fwts Test INFO 116 of 203: Test _UPP (User Presence Polling). -1.1 fwts SKIPPED: INFO Test 116, Skipping test for non-existent object _UPP. -1.1 fwts Test INFO 117 of 203: Test _GCP (Get Capabilities). -1.1 fwts WARNING: INFO Test 117, -1.1 fwts SKIPPED: INFO Test 117, Skipping test for non-existent object _GCP. -1.1 fwts Test INFO 118 of 203: Test _GRT (Get Real Time). -1.1 fwts SKIPPED: INFO Test 118, Skipping test for non-existent object _GRT. -1.1 fwts Test INFO 119 of 203: Test _GWS (Get Wake Status). -1.1 fwts WARNING: INFO Test 119, -1.1 fwts SKIPPED: INFO Test 119, Skipping test for non-existent object _GWS. -1.1 fwts Test INFO 120 of 203: Test _CWS (Clear Wake Status). -1.1 fwts SKIPPED: INFO Test 120, Skipping test for non-existent object _CWS. -1.1 fwts Test INFO 121 of 203: Test _SRT (Set Real Time). -1.1 fwts SKIPPED: INFO Test 121, Skipping test for non-existent object _SRT. -1.1 fwts Test INFO 122 of 203: Test _STP (Set Expired Timer Wake Policy). -1.1 fwts WARNING: INFO Test 122, _STP -1.1 fwts SKIPPED: INFO Test 122, Skipping test for non-existent object _STP. -1.1 fwts Test INFO 123 of 203: Test _STV (Set Timer Value). -1.1 fwts WARNING: INFO Test 123, _STV -1.1 fwts SKIPPED: INFO Test 123, Skipping test for non-existent object _STV. -1.1 fwts Test INFO 124 of 203: Test _TIP (Expired Timer Wake Policy). -1.1 fwts SKIPPED: INFO Test 124, Skipping test for non-existent object _TIP. -1.1 fwts Test INFO 125 of 203: Test _TIV (Timer Values). -1.1 fwts SKIPPED: INFO Test 125, Skipping test for non-existent object _TIV. -1.1 fwts Test INFO 126 of 203: Test _NBS (NVDIMM Boot Status). -1.1 fwts SKIPPED: INFO Test 126, Skipping test for non-existent object _NBS. -1.1 fwts Test INFO 127 of 203: Test _NCH (NVDIMM Current Health Information). -1.1 fwts SKIPPED: INFO Test 127, Skipping test for non-existent object _NCH. -1.1 fwts Test INFO 128 of 203: Test _NIC (NVDIMM Health Error Injection Capabilities). -1.1 fwts SKIPPED: INFO Test 128, Skipping test for non-existent object _NIC. -1.1 fwts Test INFO 129 of 203: Test _NIH (NVDIMM Inject/Clear Health Errors). -1.1 fwts SKIPPED: INFO Test 129, Skipping test for non-existent object _NIH. -1.1 fwts Test INFO 130 of 203: Test _NIG (NVDIMM Inject Health Error Status). -1.1 fwts SKIPPED: INFO Test 130, Skipping test for non-existent object _NIG. -1.1 fwts Test INFO 131 of 203: Test _SBS (Smart Battery Subsystem). -1.1 fwts SKIPPED: INFO Test 131, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _SBS. -1.1 fwts Test INFO 132 of 203: Test _BCT (Battery Charge Time). -1.1 fwts SKIPPED: INFO Test 132, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _BCT. -1.1 fwts Test INFO 133 of 203: Test _BIF (Battery Information). -1.1 fwts SKIPPED: INFO Test 133, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _BIF. -1.1 fwts Test INFO 134 of 203: Test _BIX (Battery Information Extended). -1.1 fwts SKIPPED: INFO Test 134, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _BIX. -1.1 fwts Test INFO 135 of 203: Test _BMA (Battery Measurement Averaging). -1.1 fwts WARNING: INFO Test 135, _BMA -1.1 fwts SKIPPED: INFO Test 135, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _BMA. -1.1 fwts Test INFO 136 of 203: Test _BMC (Battery Maintenance Control). -1.1 fwts SKIPPED: INFO Test 136, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _BMC. -1.1 fwts Test INFO 137 of 203: Test _BMD (Battery Maintenance Data). -1.1 fwts SKIPPED: INFO Test 137, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _BMD. -1.1 fwts Test INFO 138 of 203: Test _BMS (Battery Measurement Sampling Time). -1.1 fwts WARNING: INFO Test 138, _BMS -1.1 fwts SKIPPED: INFO Test 138, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _BMS. -1.1 fwts Test INFO 139 of 203: Test _BST (Battery Status). -1.1 fwts SKIPPED: INFO Test 139, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _BST. -1.1 fwts Test INFO 140 of 203: Test _BTP (Battery Trip Point). -1.1 fwts SKIPPED: INFO Test 140, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _BTP. -1.1 fwts Test INFO 141 of 203: Test _BTH (Battery Throttle Limit). -1.1 fwts SKIPPED: INFO Test 141, Skipping test for non-existent object _BTH. -1.1 fwts Test INFO 142 of 203: Test _BTM (Battery Time). -1.1 fwts SKIPPED: INFO Test 142, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _BTM. -1.1 fwts Test INFO 143 of 203: Test _PCL (Power Consumer List). -1.1 fwts WARNING: INFO Test 143, _PCL -1.1 fwts SKIPPED: INFO Test 143, Machine is not a mobile platform, skipping test for -1.1 fwts non-existent INFO mobile platform related object _PCL. -1.1 fwts Test INFO 144 of 203: Test _PIF (Power Source Information). -1.1 fwts SKIPPED: INFO Test 144, Skipping test for non-existent object _PIF. -1.1 fwts Test INFO 145 of 203: Test _PRL (Power Source Redundancy List). -1.1 fwts WARNING: INFO Test 145, _PRL -1.1 fwts SKIPPED: INFO Test 145, Skipping test for non-existent object _PRL. -1.1 fwts Test INFO 146 of 203: Test _PSR (Power Source). -1.1 fwts WARNING: INFO Test 146, _PSR -1.1 fwts SKIPPED: INFO Test 146, Skipping test for non-existent object _PSR. -1.1 fwts Test INFO 147 of 203: Test _GAI (Get Averaging Level). -1.1 fwts SKIPPED: INFO Test 147, Skipping test for non-existent object _GAI. -1.1 fwts Test INFO 148 of 203: Test _GHL (Get Harware Limit). -1.1 fwts SKIPPED: INFO Test 148, Skipping test for non-existent object _GHL. -1.1 fwts Test INFO 149 of 203: Test _PMC (Power Meter Capabilities). -1.1 fwts SKIPPED: INFO Test 149, Skipping test for non-existent object _PMC. -1.1 fwts Test INFO 150 of 203: Test _PMD (Power Meter Devices). -1.1 fwts WARNING: INFO Test 150, _PMD -1.1 fwts SKIPPED: INFO Test 150, Skipping test for non-existent object _PMD. -1.1 fwts Test INFO 151 of 203: Test _PMM (Power Meter Measurement). -1.1 fwts SKIPPED: INFO Test 151, Skipping test for non-existent object _PMM. -1.1 fwts Test INFO 152 of 203: Test _WPC (Wireless Power Calibration). -1.1 fwts WARNING: INFO Test 152, _WPC -1.1 fwts SKIPPED: INFO Test 152, Skipping test for non-existent object _WPC. -1.1 fwts Test INFO 153 of 203: Test _WPP (Wireless Power Polling). -1.1 fwts SKIPPED: INFO Test 153, Skipping test for non-existent object _WPP. -1.1 fwts Test INFO 154 of 203: Test _FIF (Fan Information). -1.1 fwts WARNING: INFO Test 154, -1.1 fwts SKIPPED: INFO Test 154, Skipping test for non-existent object _FIF. -1.1 fwts Test INFO 155 of 203: Test _FPS (Fan Performance States). -1.1 fwts SKIPPED: INFO Test 155, Skipping test for non-existent object _FPS. -1.1 fwts Test INFO 156 of 203: Test _FSL (Fan Set Level). -1.1 fwts SKIPPED: INFO Test 156, Skipping test for non-existent object _FSL. -1.1 fwts Test INFO 157 of 203: Test _FST (Fan Status). -1.1 fwts WARNING: INFO Test 157, -1.1 fwts SKIPPED: INFO Test 157, Skipping test for non-existent object _FST. -1.1 fwts Test INFO 158 of 203: Test _ACx (Active Cooling). -1.1 fwts WARNING: INFO Test 158, _AC0 -1.1 fwts SKIPPED: INFO Test 158, Skipping test for non-existent object _AC0. -1.1 fwts WARNING: INFO Test 158, _AC1 -1.1 fwts SKIPPED: INFO Test 158, Skipping test for non-existent object _AC1. -1.1 fwts WARNING: INFO Test 158, _AC2 -1.1 fwts SKIPPED: INFO Test 158, Skipping test for non-existent object _AC2. -1.1 fwts WARNING: INFO Test 158, _AC3 -1.1 fwts SKIPPED: INFO Test 158, Skipping test for non-existent object _AC3. -1.1 fwts WARNING: INFO Test 158, _AC4 -1.1 fwts SKIPPED: INFO Test 158, Skipping test for non-existent object _AC4. -1.1 fwts WARNING: INFO Test 158, _AC5 -1.1 fwts SKIPPED: INFO Test 158, Skipping test for non-existent object _AC5. -1.1 fwts WARNING: INFO Test 158, _AC6 -1.1 fwts SKIPPED: INFO Test 158, Skipping test for non-existent object _AC6. -1.1 fwts WARNING: INFO Test 158, _AC7 -1.1 fwts SKIPPED: INFO Test 158, Skipping test for non-existent object _AC7. -1.1 fwts WARNING: INFO Test 158, _AC8 -1.1 fwts SKIPPED: INFO Test 158, Skipping test for non-existent object _AC8. -1.1 fwts WARNING: INFO Test 158, _AC9 -1.1 fwts SKIPPED: INFO Test 158, Skipping test for non-existent object _AC9. -1.1 fwts Test INFO 159 of 203: Test _ART (Active Cooling Relationship Table). -1.1 fwts WARNING: INFO Test 159, _ART -1.1 fwts SKIPPED: INFO Test 159, Skipping test for non-existent object _ART. -1.1 fwts Test INFO 160 of 203: Test _ALx (Active List). -1.1 fwts WARNING: INFO Test 160, _AL0 -1.1 fwts SKIPPED: INFO Test 160, Skipping test for non-existent object _AL0. -1.1 fwts WARNING: INFO Test 160, _AL1 -1.1 fwts SKIPPED: INFO Test 160, Skipping test for non-existent object _AL1. -1.1 fwts WARNING: INFO Test 160, _AL2 -1.1 fwts SKIPPED: INFO Test 160, Skipping test for non-existent object _AL2. -1.1 fwts WARNING: INFO Test 160, _AL3 -1.1 fwts SKIPPED: INFO Test 160, Skipping test for non-existent object _AL3. -1.1 fwts WARNING: INFO Test 160, _AL4 -1.1 fwts SKIPPED: INFO Test 160, Skipping test for non-existent object _AL4. -1.1 fwts WARNING: INFO Test 160, _AL5 -1.1 fwts SKIPPED: INFO Test 160, Skipping test for non-existent object _AL5. -1.1 fwts WARNING: INFO Test 160, _AL6 -1.1 fwts SKIPPED: INFO Test 160, Skipping test for non-existent object _AL6. -1.1 fwts WARNING: INFO Test 160, _AL7 -1.1 fwts SKIPPED: INFO Test 160, Skipping test for non-existent object _AL7. -1.1 fwts WARNING: INFO Test 160, _AL8 -1.1 fwts SKIPPED: INFO Test 160, Skipping test for non-existent object _AL8. -1.1 fwts WARNING: INFO Test 160, _AL9 -1.1 fwts SKIPPED: INFO Test 160, Skipping test for non-existent object _AL9. -1.1 fwts Test INFO 161 of 203: Test _CRT (Critical Trip Point). -1.1 fwts WARNING: INFO Test 161, _CRT -1.1 fwts SKIPPED: INFO Test 161, Skipping test for non-existent object _CRT. -1.1 fwts Test INFO 162 of 203: Test _CR3 (Warm/Standby Temperature). -1.1 fwts WARNING: INFO Test 162, _CR3 -1.1 fwts SKIPPED: INFO Test 162, Skipping test for non-existent object _CR3. -1.1 fwts Test INFO 163 of 203: Test _DTI (Device Temperature Indication). -1.1 fwts SKIPPED: INFO Test 163, Skipping test for non-existent object _DTI. -1.1 fwts Test INFO 164 of 203: Test _HOT (Hot Temperature). -1.1 fwts WARNING: INFO Test 164, _HOT -1.1 fwts SKIPPED: INFO Test 164, Skipping test for non-existent object _HOT. -1.1 fwts Test INFO 165 of 203: Test _MTL (Minimum Throttle Limit). -1.1 fwts SKIPPED: INFO Test 165, Skipping test for non-existent object _MTL. -1.1 fwts Test INFO 166 of 203: Test _NTT (Notification Temp Threshold). -1.1 fwts WARNING: INFO Test 166, _NTT -1.1 fwts SKIPPED: INFO Test 166, Skipping test for non-existent object _NTT. -1.1 fwts Test INFO 167 of 203: Test _PSL (Passive List). -1.1 fwts WARNING: INFO Test 167, _PSL -1.1 fwts SKIPPED: INFO Test 167, Skipping test for non-existent object _PSL. -1.1 fwts Test INFO 168 of 203: Test _PSV (Passive Temp). -1.1 fwts WARNING: INFO Test 168, _PSV -1.1 fwts SKIPPED: INFO Test 168, Skipping test for non-existent object _PSV. -1.1 fwts Test INFO 169 of 203: Test _RTV (Relative Temp Values). -1.1 fwts SKIPPED: INFO Test 169, Skipping test for non-existent object _RTV. -1.1 fwts Test INFO 170 of 203: Test _SCP (Set Cooling Policy). -1.1 fwts SKIPPED: INFO Test 170, Skipping test for non-existent object _DTI. -1.1 fwts Test INFO 171 of 203: Test _TC1 (Thermal Constant 1). -1.1 fwts SKIPPED: INFO Test 171, Skipping test for non-existent object _TC1. -1.1 fwts Test INFO 172 of 203: Test _TC2 (Thermal Constant 2). -1.1 fwts SKIPPED: INFO Test 172, Skipping test for non-existent object _TC2. -1.1 fwts Test INFO 173 of 203: Test _TFP (Thermal fast Sampling Period). -1.1 fwts SKIPPED: INFO Test 173, Skipping test for non-existent object _TFP. -1.1 fwts Test INFO 174 of 203: Test _TMP (Thermal Zone Current Temp). -1.1 fwts WARNING: INFO Test 174, _TMP -1.1 fwts SKIPPED: INFO Test 174, Skipping test for non-existent object _TMP. -1.1 fwts Test INFO 175 of 203: Test _TPT (Trip Point Temperature). -1.1 fwts SKIPPED: INFO Test 175, Skipping test for non-existent object _TPT. -1.1 fwts Test INFO 176 of 203: Test _TRT (Thermal Relationship Table). -1.1 fwts WARNING: INFO Test 176, _TRT -1.1 fwts SKIPPED: INFO Test 176, Skipping test for non-existent object _TRT. -1.1 fwts Test INFO 177 of 203: Test _TSN (Thermal Sensor Device). -1.1 fwts WARNING: INFO Test 177, _TSN -1.1 fwts SKIPPED: INFO Test 177, Skipping test for non-existent object _TSN. -1.1 fwts Test INFO 178 of 203: Test _TSP (Thermal Sampling Period). -1.1 fwts WARNING: INFO Test 178, _TSP -1.1 fwts SKIPPED: INFO Test 178, Skipping test for non-existent object _TSP. -1.1 fwts Test INFO 179 of 203: Test _TST (Temperature Sensor Threshold). -1.1 fwts WARNING: INFO Test 179, _TST -1.1 fwts SKIPPED: INFO Test 179, Skipping test for non-existent object _TST. -1.1 fwts Test INFO 180 of 203: Test _TZD (Thermal Zone Devices). -1.1 fwts WARNING: INFO Test 180, _TZD -1.1 fwts SKIPPED: INFO Test 180, Skipping test for non-existent object _TZD. -1.1 fwts Test INFO 181 of 203: Test _TZM (Thermal Zone member). -1.1 fwts WARNING: INFO Test 181, _TZM -1.1 fwts SKIPPED: INFO Test 181, Skipping test for non-existent object _TZM. -1.1 fwts Test INFO 182 of 203: Test _TZP (Thermal Zone Polling). -1.1 fwts WARNING: INFO Test 182, _TZP -1.1 fwts SKIPPED: INFO Test 182, Skipping test for non-existent object _TZP. -1.1 fwts Test INFO 183 of 203: Test _GPE (General Purpose Events). -1.1 fwts WARNING: INFO Test 183, _GPE -1.1 fwts SKIPPED: INFO Test 183, Skipping test for non-existent object _GPE. -1.1 fwts Test INFO 184 of 203: Test _EC_ (EC Offset Query). -1.1 fwts SKIPPED: INFO Test 184, Skipping test for non-existent object _EC_. -1.1 fwts Test INFO 185 of 203: Test _PTS (Prepare to Sleep). -1.1 fwts Test INFO 186 of 203: Test _TTS (Transition to State). -1.1 fwts SKIPPED: INFO Test 186, Optional control method _TTS does not exist. -1.1 fwts Test INFO 187 of 203: Test _WAK (System Wake). -1.1 fwts Test INFO 188 of 203: Test _ADR (Return Unique ID for Device). -1.1 fwts FAILED INFO [MEDIUM] MethodNotExist: Test 188, Object _ADR did not exist. -1.1 fwts SKIPPED: INFO Test 188, Skipping test for non-existent object _ADR. -1.1 fwts Test INFO 189 of 203: Test _BCL (Query List of Brightness Control Levels Supported). -1.1 fwts SKIPPED: INFO Test 189, Skipping test for non-existent object _BCL. -1.1 fwts Test INFO 190 of 203: Test _BCM (Set Brightness Level). -1.1 fwts SKIPPED: INFO Test 190, Skipping test for non-existent object _BCM. -1.1 fwts Test INFO 191 of 203: Test _BQC (Brightness Query Current Level). -1.1 fwts SKIPPED: INFO Test 191, Skipping test for non-existent object _BQC. -1.1 fwts Test INFO 192 of 203: Test _DCS (Return the Status of Output Device). -1.1 fwts WARNING: INFO Test 192, -1.1 fwts SKIPPED: INFO Test 192, Skipping test for non-existent object _DCS. -1.1 fwts Test INFO 193 of 203: Test _DSS (Device Set State). -1.1 fwts SKIPPED: INFO Test 193, Skipping test for non-existent object _DSS. -1.1 fwts Test INFO 194 of 203: Test _DGS (Query Graphics State). -1.1 fwts WARNING: INFO Test 194, -1.1 fwts SKIPPED: INFO Test 194, Skipping test for non-existent object _DGS. -1.1 fwts Test INFO 195 of 203: Test _DOD (Enumerate All Devices Attached to Display Adapter). -1.1 fwts SKIPPED: INFO Test 195, Skipping test for non-existent object _DOD. -1.1 fwts Test INFO 196 of 203: Test _DOS (Enable/Disable Output Switching). -1.1 fwts SKIPPED: INFO Test 196, Skipping test for non-existent object _DOS. -1.1 fwts Test INFO 197 of 203: Test _GPD (Get POST Device). -1.1 fwts WARNING: INFO Test 197, -1.1 fwts SKIPPED: INFO Test 197, Skipping test for non-existent object _GPD. -1.1 fwts Test INFO 198 of 203: Test _ROM (Get ROM Data). -1.1 fwts SKIPPED: INFO Test 198, Skipping test for non-existent object _ROM. -1.1 fwts Test INFO 199 of 203: Test _SPD (Set POST Device). -1.1 fwts SKIPPED: INFO Test 199, Skipping test for non-existent object _SPD. -1.1 fwts Test INFO 200 of 203: Test _VPO (Video POST Options). -1.1 fwts WARNING: INFO Test 200, -1.1 fwts SKIPPED: INFO Test 200, Skipping test for non-existent object _VPO. -1.1 fwts Test INFO 201 of 203: Test _CBA (Configuration Base Address). -1.1 fwts SKIPPED: INFO Test 201, Skipping test for non-existent object _CBA. -1.1 fwts Test INFO 202 of 203: Test _IFT (IPMI Interface Type). -1.1 fwts SKIPPED: INFO Test 202, Skipping test for non-existent object _IFT. -1.1 fwts Test INFO 203 of 203: Test _SRV (IPMI Interface Revision). -1.1 fwts SKIPPED: INFO Test 203, Skipping test for non-existent object _SRV. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 93 INFO passed, 1 failed, 99 warnings, 0 aborted, 203 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts madt: INFO MADT Multiple APIC Description Table (spec compliant). -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 5: MADT checksum test. -1.1 fwts PASSED: INFO Test 1, MADT checksum is correct -1.1 fwts Test INFO 2 of 5: MADT revision test. -1.1 fwts Most INFO recent FADT revision is 6.2. -1.1 fwts Most INFO recent MADT revision is 4. -1.1 fwts PASSED: INFO Test 2, MADT revision 4 is defined. -1.1 fwts PASSED: INFO Test 2, MADT revision 4 is in sync with FADT revision 6.2. -1.1 fwts Test INFO 3 of 5: MADT architecture minimum revision test. -1.1 fwts PASSED: INFO Test 3, MADT revision 4 meets the minimum needed (3) for the aarch64 -1.1 fwts architecture. INFO architecture. -1.1 fwts Test INFO 4 of 5: MADT flags field reserved bits test. -1.1 fwts PASSED: INFO Test 4, MADT flags reserved bits are not set. -1.1 fwts Test INFO 5 of 5: MADT subtable tests. -1.1 fwts PASSED: INFO Test 5, MADT revision 4 is defined. -1.1 fwts PASSED: INFO Test 5, MADT subtable type 11 (GICC CPU Interface) is defined. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface reserved field properly set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC has matching processor UID 0. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, flags, bits 3..31 are reserved and -1.1 fwts properly INFO set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, is using a defined parking protocol -1.1 fwts version. INFO version. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface second reserved field properly set to -1.1 fwts zero. INFO zero. -1.1 fwts PASSED: INFO Test 5, MADT subtable type 11 (GICC CPU Interface) is defined. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface reserved field properly set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC has matching processor UID 1. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, flags, bits 3..31 are reserved and -1.1 fwts properly INFO set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, is using a defined parking protocol -1.1 fwts version. INFO version. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface second reserved field properly set to -1.1 fwts zero. INFO zero. -1.1 fwts PASSED: INFO Test 5, MADT subtable type 11 (GICC CPU Interface) is defined. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface reserved field properly set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC has matching processor UID 2. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, flags, bits 3..31 are reserved and -1.1 fwts properly INFO set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, is using a defined parking protocol -1.1 fwts version. INFO version. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface second reserved field properly set to -1.1 fwts zero. INFO zero. -1.1 fwts PASSED: INFO Test 5, MADT subtable type 11 (GICC CPU Interface) is defined. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface reserved field properly set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC has matching processor UID 3. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, flags, bits 3..31 are reserved and -1.1 fwts properly INFO set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, is using a defined parking protocol -1.1 fwts version. INFO version. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface second reserved field properly set to -1.1 fwts zero. INFO zero. -1.1 fwts PASSED: INFO Test 5, MADT subtable type 11 (GICC CPU Interface) is defined. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface reserved field properly set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC has matching processor UID 4. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, flags, bits 3..31 are reserved and -1.1 fwts properly INFO set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, is using a defined parking protocol -1.1 fwts version. INFO version. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface second reserved field properly set to -1.1 fwts zero. INFO zero. -1.1 fwts PASSED: INFO Test 5, MADT subtable type 11 (GICC CPU Interface) is defined. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface reserved field properly set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC has matching processor UID 5. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, flags, bits 3..31 are reserved and -1.1 fwts properly INFO set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, is using a defined parking protocol -1.1 fwts version. INFO version. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface second reserved field properly set to -1.1 fwts zero. INFO zero. -1.1 fwts PASSED: INFO Test 5, MADT subtable type 11 (GICC CPU Interface) is defined. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface reserved field properly set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC has matching processor UID 6. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, flags, bits 3..31 are reserved and -1.1 fwts properly INFO set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, is using a defined parking protocol -1.1 fwts version. INFO version. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface second reserved field properly set to -1.1 fwts zero. INFO zero. -1.1 fwts PASSED: INFO Test 5, MADT subtable type 11 (GICC CPU Interface) is defined. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface reserved field properly set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC has matching processor UID 7. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, flags, bits 3..31 are reserved and -1.1 fwts properly INFO set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface, is using a defined parking protocol -1.1 fwts version. INFO version. -1.1 fwts PASSED: INFO Test 5, MADT GICC CPU Interface second reserved field properly set to -1.1 fwts zero. INFO zero. -1.1 fwts PASSED: INFO Test 5, MADT subtable type 12 (GICD GIC Distributor) is defined. -1.1 fwts PASSED: INFO Test 5, MADT GICD GIC Distributor reserved field properly set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICD GIC Distributor system vector base field is properly -1.1 fwts set INFO to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICD GIC Distributor GIC version field is in 0..4. -1.1 fwts PASSED: INFO Test 5, MADT GICD GIC Distributor second reserved field is properly set -1.1 fwts to INFO zero. -1.1 fwts PASSED: INFO Test 5, MADT subtable type 14 (GICR Redistributor) is defined. -1.1 fwts PASSED: INFO Test 5, MADT GICR Redistributor reserved field properly set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GICR Redistributor discovery range length of 1048576 > 0. -1.1 fwts PASSED: INFO Test 5, MADT subtable type 15 (GIC Interrupt Translation Service (ITS)) -1.1 fwts is INFO defined. -1.1 fwts PASSED: INFO Test 5, MADT GIC Interrupt Translation Service (ITS) first reserved -1.1 fwts field INFO is properly set to zero. -1.1 fwts PASSED: INFO Test 5, MADT GIC Interrupt Translation Service (ITS) ITS ID 0x0 is -1.1 fwts unique INFO as is required. -1.1 fwts PASSED: INFO Test 5, MADT GIC Interrupt Translation Service (ITS) second reserved -1.1 fwts field INFO is properly set to zero. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 66 INFO passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts hest: INFO HEST Hardware Error Source Table test. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 1: HEST Hardware Error Source Table test. -1.1 fwts HEST INFO Hardware Error Source Table test -1.1 fwts Error INFO Source Count: 0x02 -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 0 INFO passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts gtdt: INFO GTDT Generic Timer Description Table test. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 1: GTDT Generic Timer Description Table test. -1.1 fwts PASSED: INFO Test 1, No issues found in GTDT table. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 1 INFO passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts fadt_sbbr: INFO SBBR FADT Fixed ACPI Description Table tests. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 4: FADT Revision Test. -1.1 fwts FADT INFO revision: 6.2 -1.1 fwts PASSED: INFO Test 1, FADT revision is up to date. -1.1 fwts Test INFO 2 of 4: FADT Reduced HW Test. -1.1 fwts PASSED: INFO Test 2, FADT indicates ACPI is in reduced hardware mode. -1.1 fwts PASSED: INFO Test 2, All FADT reduced hardware fields are zero. -1.1 fwts PASSED: INFO Test 2, All FADT reduced hardware flags are not set. -1.1 fwts PASSED: INFO Test 2, FADT APIC flags are not set in reduced hardware mode. -1.1 fwts Test INFO 3 of 4: FADT Server Profile Test. -1.1 fwts FADT INFO Preferred PM Profile: 4 (Enterprise Server) -1.1 fwts PASSED: INFO Test 3, FADT has a recommended server PM profile. -1.1 fwts Test INFO 4 of 4: FADT PSCI Compliant Test. -1.1 fwts PASSED: INFO Test 4, PSCI_COMPLIANT is set, PSCI is implemented. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 7 INFO passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts acpi_rc: INFO ACPI PCIe Root Complex resources test -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts PCIe INFO Root Complex Device: \_SB_.PCI0 -1.1 fwts Test INFO 1 of 1: Test _CRS (Current Resource Settings). -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 0 INFO passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts acpi_ged: INFO ACPI Generic Event Device test -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts ACPI INFO GED Device: \_SB_.GED0 -1.1 fwts Test INFO 1 of 2: Test _CRS (Current Resource Settings). -1.1 fwts PASSED: INFO Test 1, _CRS (Extended IRQ Descriptor) looks sane. -1.1 fwts Test INFO 2 of 2: Test _EVT (Event). -1.1 fwts ACPICA INFO Exception AE_AML_UNINITIALIZED_ARG during execution of method _EVT -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 1 INFO passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts dbg2: INFO DBG2 (Debug Port Table 2) test. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 2: DBG2 (Debug Port Table 2) test. -1.1 fwts DBG2 INFO Table: -1.1 fwts Info INFO Offset: 0x0000002c -1.1 fwts Info INFO Count: 0x00000001 -1.1 fwts DBG2 INFO Info Structure 0: -1.1 fwts Revision: INFO 0x00 -1.1 fwts Length: INFO 0x0032 -1.1 fwts Number INFO of Registers 0x01 -1.1 fwts Namespace INFO String Length: 0x000c -1.1 fwts Namespace INFO String Offset: 0x0026 -1.1 fwts OEM INFO Data Length: 0x0000 -1.1 fwts OEM INFO Data Offset: 0x0000 -1.1 fwts Port INFO Type: 0x8000 (Serial) -1.1 fwts Port INFO Subtype: 0x0003 (ARMPL011 UART) -1.1 fwts Reserved: INFO 0x0000 -1.1 fwts Base INFO Address Offset: 0x0016 -1.1 fwts Address INFO Size Offset: 0x0022 -1.1 fwts Namespace INFO String: '\_SB.COM0' -1.1 fwts Address INFO Space ID: 0x00 -1.1 fwts Register INFO Bit Width 0x20 -1.1 fwts Register INFO Bit Offset 0x00 -1.1 fwts Access INFO Size 0x03 -1.1 fwts Address INFO 0x000000007ff80000 -1.1 fwts PASSED: INFO Test 1, No issues found in DBG2 table. -1.1 fwts Test INFO 2 of 2: DBG2 ARM SBSA Generic UART test, -1.1 fwts PASSED: INFO Test 2, DBG2 provides a standard serial debug port and describes ARM -1.1 fwts SBSA INFO Generic UART -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 2 INFO passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts acpi_sbbr: INFO ACPI table headers sanity tests. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 3: Test that processors only exist in the _SB namespace. -1.1 fwts PASSED: INFO Test 1, All processor devices were located in the _SB_ namespace. -1.1 fwts Test INFO 2 of 3: Test DSDT and SSDT tables are implemented. -1.1 fwts PASSED: INFO Test 2, Table DSDT has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 2, Table SSDT has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 2, Table SSDT has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 2, Table SSDT has valid signature and ID strings. -1.1 fwts Test INFO 3 of 3: Check for recommended ACPI tables. -1.1 fwts PASSED: INFO Test 3, SBBR Recommended ACPI table "MCFG" found. -1.1 fwts PASSED: INFO Test 3, SBBR Recommended ACPI table "IORT" found. -1.1 fwts WARNING: INFO Test 3, SBBR Recommended ACPI table "BERT" not found. -1.1 fwts WARNING: INFO Test 3, SBBR Recommended ACPI table "EINJ" not found. -1.1 fwts WARNING: INFO Test 3, SBBR Recommended ACPI table "ERST" not found. -1.1 fwts PASSED: INFO Test 3, SBBR Recommended ACPI table "HEST" found. -1.1 fwts WARNING: INFO Test 3, SBBR Recommended ACPI table "SPMI" not found. -1.1 fwts WARNING: INFO Test 3, SBBR Recommended ACPI table "SLIT" not found. -1.1 fwts WARNING: INFO Test 3, SBBR Recommended ACPI table "SRAT" not found. -1.1 fwts WARNING: INFO Test 3, SBBR Recommended ACPI table "PCCT" not found. -1.1 fwts PASSED: INFO Test 3, SBBR Recommended ACPI table "SDEI" found. -1.1 fwts PASSED: INFO Test 3, SBBR Recommended ACPI table "PPTT" found. -1.1 fwts WARNING: INFO Test 3, SBBR Recommended ACPI table "PDTT" not found. -1.1 fwts WARNING: INFO Test 3, SBBR Recommended ACPI table "NFIT" not found. -1.1 fwts WARNING: INFO Test 3, SBBR Recommended ACPI table "HMAT" not found. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 10 INFO passed, 0 failed, 10 warnings, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts acpitables: INFO ACPI table headers sanity tests. -1.1 fwts -------------------------------------------------------------------------------- INFO -------------------------------------------------------------------------------- -1.1 fwts Test INFO 1 of 2: Test ACPI headers. -1.1 fwts PASSED: INFO Test 1, Table APIC has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table DBG2 has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table DSDT has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table FACP has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table GTDT has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table HEST has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table IORT has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table MCFG has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table PPTT has valid signature and ID strings. -1.1 fwts WARNING: INFO Test 1, ACPI Table SDEI is empty and just contains a table header. -1.1 fwts Further INFO header checks will be omitted. -1.1 fwts PASSED: INFO Test 1, Table SPCR has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table SSDT has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table SSDT has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table SSDT has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table RSDT has valid signature and ID strings. -1.1 fwts PASSED: INFO Test 1, Table XSDT has valid signature and ID strings. -1.1 fwts Test INFO 2 of 2: Test ACPI spec versus table revisions. -1.1 fwts System INFO supports ACPI 0620 -1.1 fwts Table INFO APIC has a matched revision. -1.1 fwts Table INFO DSDT has a matched revision. -1.1 fwts Table INFO GTDT has a matched revision. -1.1 fwts Table INFO HEST has a matched revision. -1.1 fwts Table INFO SSDT has a matched revision. -1.1 fwts Table INFO SSDT has a matched revision. -1.1 fwts Table INFO SSDT has a matched revision. -1.1 fwts Table INFO RSDT has a matched revision. -1.1 fwts Table INFO XSDT has a matched revision. -1.1 fwts PASSED: INFO Test 2, ACPI spec 0620 has matched table revisions. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 16 INFO passed, 0 failed, 1 warning, 0 aborted, 0 skipped, 0 info only. -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts 271 INFO passed, 1 failed, 111 warnings, 0 aborted, 244 skipped, 1 info only. -1.1 fwts Test INFO Failure Summary -1.1 fwts ================================================================================ INFO ================================================================================ -1.1 fwts Critical INFO failures: NONE -1.1 fwts High INFO failures: NONE -1.1 fwts Medium INFO failures: 1 -1.1 fwts method: INFO Object _ADR did not exist. -1.1 fwts Low INFO failures: NONE -1.1 fwts Other INFO failures: NONE -1.1 fwts Test INFO |Pass |Fail |Abort|Warn |Skip |Info | -1.1 fwts ---------------+-----+-----+-----+-----+-----+-----+ INFO ---------------+-----+-----+-----+-----+-----+-----+ -1.1 fwts acpi_ged INFO | 1| | | | | | -1.1 fwts acpi_rc INFO | | | | | | | -1.1 fwts acpi_sbbr INFO | 10| | | 10| | | -1.1 fwts acpiinfo INFO | | | | | | 1| -1.1 fwts acpitables INFO | 16| | | 1| | | -1.1 fwts dbg2 INFO | 2| | | | | | -1.1 fwts dmicheck INFO | 26| | | | 9| | -1.1 fwts fadt_sbbr INFO | 7| | | | | | -1.1 fwts gtdt INFO | 1| | | | | | -1.1 fwts hest INFO | | | | | | | -1.1 fwts madt INFO | 66| | | | | | -1.1 fwts method INFO | 93| 1| | 99| 203| | -1.1 fwts rsdp_sbbr INFO | 1| | | | | | -1.1 fwts spcr INFO | 3| | | | | | -1.1 fwts uefirtmisc INFO | 3| | | | 11| | -1.1 fwts uefirttime INFO | 16| | | | 20| | -1.1 fwts uefirtvariable INFO | 25| | | 1| 1| | -1.1 fwts xsdt INFO | 1| | | | | | -1.1 fwts ---------------+-----+-----+-----+-----+-----+-----+ INFO ---------------+-----+-----+-----+-----+-----+-----+ -1.1 fwts Total: INFO | 271| 1| 0| 111| 244| 1| -1.1 fwts ---------------+-----+-----+-----+-----+-----+-----+ INFO ---------------+-----+-----+-----+-----+-----+-----+ diff --git a/docs/rdn1edge/acs-results/rdn1edge-sbsa-linux.log b/docs/rdn1edge/acs-results/rdn1edge-sbsa-linux.log deleted file mode 100755 index eb6891e..0000000 --- a/docs/rdn1edge/acs-results/rdn1edge-sbsa-linux.log +++ /dev/null @@ -1,59 +0,0 @@ - - ************ SBSA Architecture Compliance Suite ********* - Version 2.5 - - Starting tests for level 4 (Print level is 3) - - Gathering system information.... - PE_INFO: Number of PE detected : 8 - PCIE_INFO: Number of ECAM regions : 1 - Peripheral: Num of USB controllers : 0 - Peripheral: Num of SATA controllers : 3 - Peripheral: Num of UART controllers : 0 - DMA_INFO: Number of DMA CTRL in PCIe : 0 - SMMU_INFO: Number of SMMU CTRL : 0 - - *** Starting PCIe tests *** - 401 : Check ECAM Presence : Result: PASS - 402 : Check ECAM value in MCFG table : Result: PASS - 404 : PCIe Unaligned access, Norm mem : Result: PASS - 405 : DMA Address translations (SATA) - No DMA controllers detected... : Result: -SKIPPED- 1 - 406 : No extra addr translation - SMMU - No DMA controllers detected... : Result: -SKIPPED- 2 - 407 : Check MSI support for PCIe device : Result: PASS - 408 : Check MSI(X) vectors uniqueness : Result: PASS - 409 : Check all MSI(X) vectors are LPIs : Result: PASS - 411 : PCIe RC & PE, Same Inner SH Domain: Result: PASS - 412 : PCI legacy interrupt SPI ID unique - Unable to fetch _PRT ACPI handle - Unable to fetch _PRT ACPI handle - Unable to fetch _PRT ACPI handle - Unable to fetch _PRT ACPI handle - Unable to fetch _PRT ACPI handle - Unable to fetch _PRT ACPI handle - Interrupt hard-wire error - Interrupt hard-wire error - Interrupt hard-wire error: Result: PASS - 410 : PASID support atleast 16 bits : Result: -SKIPPED- 3 - 413 : Addressability of Non-Sec masters - WARNING:The device with bdf=0x80001 doesn't support 64 bit addressing - and is not behind SMMU. Please install driver for this device and - test again. If driver is already installed, this test has failed. - The device is of type = 1 - Failed on PE - 0 for Level= 4 : Result: --FAIL-- 1 - 414 : Memory attributes of DMA traffic - No DMA controllers detected... : Result: -SKIPPED- 3 - 415 : PCIe No Snoop transaction attr : Result: PASS - 416 : NP type-1 pcie only support 32-bit: Result: -SKIPPED- 3 - 417 : Root port must implement minimal ACS features if P2P supported: Result: -SKIPPED- 3 - 418 : All switches must implement minimal ACS features if P2P supported: Result: -SKIPPED- 3 - 419 : Multifunction devices must implement minimal ACS features if P2P supported: Result: -SKIPPED- 3 - - One or more PCIe tests have failed.... - - ------------------------------------------------------------ - Total Tests Run = 18, Tests Passed = 9, Tests Failed = 1 - ------------------------------------------------------------ - *** SBSA tests complete *** - diff --git a/docs/rdn1edge/acs-results/rdn1edge-sbsa.log b/docs/rdn1edge/acs-results/rdn1edge-sbsa.log deleted file mode 100755 index 90b6c0b..0000000 --- a/docs/rdn1edge/acs-results/rdn1edge-sbsa.log +++ /dev/null @@ -1,138 +0,0 @@ - PE_INFO: Number of PE detected : 8
- GIC_INFO: Number of GICD : 1
- GIC_INFO: Number of ITS : 1
- TIMER_INFO: Number of system timers : 2
- WATCHDOG_INFO: Number of Watchdogs : 2
- PCIE_INFO: Number of ECAM regions : 1
- SMMU_INFO: Number of SMMU CTRL : 0
- Peripheral: Num of USB controllers : 0
- Peripheral: Num of SATA controllers : 2
- Peripheral: Num of UART controllers : 1
- 1 : Check for number of PE : Result: PASS
- 2 : Check for SIMD extensions : Result: PASS
- 3 : Check for 16-bit ASID support : Result: PASS
- 4 : Check MMU Granule sizes : Result: PASS
- 5 : Check Cache Architecture : Result: PASS
- 6 : Check HW Coherence support : Result: PASS
- 7 : Check Cryptographic extensions
- Failed on PE - 0 for Level= 4 : Result: --FAIL-- 1
- 8 : Check Little Endian support : Result: PASS
- 9 : Check EL2 implementation : Result: PASS
- 10 : Check AARCH64 implementation : Result: PASS
- 11 : Check PMU Overflow signal : Result: PASS
- 12 : Check number of PMU counters : Result: PASS
- 13 : Check Synchronous Watchpoints : Result: PASS
- 14 : Check number of Breakpoints : Result: PASS
- 15 : Check Arch symmetry across PE : Result: PASS
- 16 : Check EL3 implementation : Result: PASS
- 17 : Check CRC32 instruction support : Result: PASS
- 18 : Check for PMBIRQ signal
- ARM-TF firmware not ported, skipping this test: Result: -SKIPPED- 2
- 19 : Check for RAS extension : Result: PASS
- 20 : Check for 16-Bit VMID : Result: PASS
- 21 : Check for Virtual host extensions : Result: PASS
- 22 : Check for pointer signing : Result: -SKIPPED- 1
-
- *** One or more PE tests have failed... ***
- 101 : Check GIC version : Result: PASS
- 102 : If PCIe, then GIC implements ITS : Result: PASS
- 103 : GIC number of Security states(2) : Result: PASS
- 104 : GIC Maintenance Interrupt : Result: PASS
-
- All GIC tests Passed!!
- 201 : Check Counter Frequency : Result: PASS
- 202 : Check EL0-Phy timer interrupt : Result: PASS
- 203 : Check EL0-Virtual timer interrupt : Result: PASS
- 204 : Check EL2-phy timer interrupt : Result: PASS
- 205 : Check EL2-Virtual timer interrupt : Result: PASS
- 206 : SYS Timer if PE Timer not ON : Result: PASS
- 207 : CNTCTLBase & CNTBaseN access : Result: PASS
- 208 : Generate Mem Mapped SYS Timer Intr: Result: PASS
-
- All Timer tests passed!!
- 301 : Check NS Watchdog Accessibility : Result: PASS
- 302 : Check Watchdog WS0 interrupt : Result: PASS
-
- All Watchdog tests passed!!
- 401 : Check ECAM Presence : Result: PASS
- 402 : Check ECAM value in MCFG table : Result: PASS
- 420 : Check Type 0/1 common config rules: Result: PASS
- 421 : Check Type 0 config header rules : Result: PASS
- 422 : Check Type 1 config header rules : Result: PASS
- 423 : Check PCIe capability rules : Result: -SKIPPED- 1
- 424 : Check Device capabilites reg rules: Result: PASS
- 425 : Check Device Control register rule: Result: PASS
- 426 : Check Device cap 2 register rules : Result: PASS
- 427 : Check Device control 2 reg rules : Result: PASS
- 428 : Check Power management cap rules : Result: PASS
- 429 : Check Power management/status rule: Result: PASS
- 430 : Check Cmd Reg memory space enable : Result: PASS
- 431 : Check Type0/1 BIST Register rule : Result: PASS
- 432 : Check HDR CapPtr Register rule : Result: PASS
- 433 : Check Max payload size supported : Result: PASS
- 434 : Check BAR memory space & Type rule: Result: PASS
- 435 : Check Function level reset rule : Result: PASS
- 436 : Check ARI forwarding support rule : Result: -SKIPPED- 1
- 437 : Check OBFF supported rule : Result: -SKIPPED- 1
- 438 : Check CTRS and CTDS rule : Result: -SKIPPED- 1
- 439 : Check i-EP atomicop rule : Result: -SKIPPED- 1
- 440 : Check Rootport ATS and PRI rule : Result: PASS
- 441 : Check MSI and MSI-X support rule : Result: PASS
- 442 : Check Power Management rules : Result: PASS
- 443 : Check ARI forwarding enable rule : Result: PASS
- 444 : Check device under RP in same ECAM: Result: PASS
- 445 : Check all RP in HB is in same ECAM: Result: PASS
-
- One or more PCIe tests have failed....
- TEST Wakeup from Power Semantic B
- 501 : Wake from EL0 PHY Timer Interrupt : Result: PASS
- 502 : Wake from EL0 VIRT Timer Interrupt: Result: PASS
- 503 : Wake from EL2 PHY Timer Interrupt : Result: PASS
- 504 : Wake from Watchdog WS0 Interrupt : Result: PASS
- 505 : Wake from System Timer Interrupt : Result: PASS
- 601 : Check USB CTRL Interface via PCIe : Result: -SKIPPED- 1
- 602 : Check SATA CTRL Interface via PCIe: Result: PASS
- 603 : Check SBSA UART register offsets : Result: PASS
- 604 : Check GENERIC UART Interrupt : Result: PASS
- 605 : Memory Access to Un-Populated addr: Result: PASS
- 701 : Check 64KB Granularity support
- No SMMU Controllers are discovered : Result: -SKIPPED- 1
- 702 : All SMMUs have same Arch Revision
- No SMMU Controllers are discovered : Result: -SKIPPED- 1
- 703 : SMMU Compatibility Check
- No SMMU Controllers are discovered : Result: -SKIPPED- 1
- 704 : If PCIe, Check Stall model
- No SMMU Controllers are discovered : Result: -SKIPPED- 1
- 705 : SMMUv2 unique intr per ctxt bank
- No SMMU Controllers are discovered : Result: -SKIPPED- 3
- 706 : Unique stream id for each req id : Result: PASS
-
- One or more SMMU tests have failed...
- 801 : Enhanced ECAM Memory access check : Result: PASS
- 802 : PCIe BAR access check : Result: PASS
- 803 : PCIe Address translation check : Result: PASS
- 804 : Generate MSI(X) interrupts
- MSI Assignment failed for bdf : 0x60007
- Failed on PE - 0 for Level= 4 : Result: --FAIL-- 1
- 805 : Generate PASID PCIe transactions : Result: PASS
- 806 : Generate PCIe legacy interrupts
- Invalid Interrupt ID number -1347440721
- Failed on PE - 0 for Level= 4 : Result: --FAIL-- 2
- 807 : Check PCI Express I/O Coherency
- WB and OSH mem alloc failure 2
- Failed on PE - 0 for Level= 4 : Result: --FAIL-- 2
- 808 : Check BME functionality of RP : Result: PASS
- 809 : Check RP Sec Bus transactions are TYPE0
- BDF 0x200 Sec Bus Transaction failure
- BDF 0x200 Sec Bus Transaction failure
- Failed on PE - 0 for Level= 4 : Result: --FAIL-- 2
- 810 : Check RP Sub Bus transactions are TYPE1
- BDF 0x200 Sub Bus Transaction failure
- BDF 0x200 Sub Bus Transaction failure
- Failed on PE - 0 for Level= 4 : Result: --FAIL-- 2
-
- One or more Exerciser tests have failed....
-
- -------------------------------------------------------
- Total Tests run = 90; Tests Passed = 71 Tests Failed = 6
- ---------------------------------------------------------
diff --git a/docs/rdn1edge/how-to/acs-test.rst b/docs/rdn1edge/how-to/acs-test.rst deleted file mode 100644 index bca50eb..0000000 --- a/docs/rdn1edge/how-to/acs-test.rst +++ /dev/null @@ -1,138 +0,0 @@ -How to build RD-N1-Edge platform software and execute Arm ACS test suite -======================================================================== - - -.. section-numbering:: - :suffix: . - -.. contents:: - -What is Arm ACS ---------------- - -Architecture Compliance Suite (ACS) is used to ensure architectural compliance -across different implementations of the architecture. Arm Enterprise ACS -includes a set of examples of the invariant behaviours that are provided by a -set of specifications for enterprise systems (e.g. SBSA, SBBR, etc.), so that -implementers can verify if these behaviours have been interpreted correctly. -ACS is delivered with tests in source form along with a build script, the output -of the build being a bootable Linux UEFI Validation (LUV) OS image that can run -all tests required by these specifications. - -What does ACS test on RD-N1-Edge demonstrate --------------------------------------------- - -RD-N1-Edge platform is targetted for enterprise and network infrastructure -use cases. This requires the RD-N1-Edge platform to be compliant to the various -architectural specifications such as SBSA and SBBR. The ACS test on RD-N1-Edge -platform helps with building the platform firmware stack and ACS test suite -and then validating the same on the RD-N1-Edge platform. The test results are -stored on the luv-live disk image which can be retrived from this disk. The -results can then be looked into to determine the conformance to the SBSA and -SBBR standards. - -Procedure to build for ACS test on RD-N1-Edge platform ------------------------------------------------------- - -The procedure to build the RD-N1-Edge platform software stack is listed below. -The components of the RD-N1-Edge platform software stack that are built is -limited to those that provide the EFI implementation and the EFI shell on the -RD-N1-Edge platforms (i.e, SCP, TF-A and EDK2). The command to be used to -build these firmware components is - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge all - - - This command cleans, builds and packages the RD-N1-Edge software stack - required for the ACS test on RD-N1-Edge platform. - - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge build - - - This command performs an incremental build of the software components - included in the software stack for ACS test on the RD-N1-Edge platform. - Note: this command should be followed by the 'package' command to - complete the preparation of the fip image. - - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge package - - - This command packages the previously build software stack and prepares - the fip image. - - -Procedure for executing ACS test for RD-N1-Edge platform --------------------------------------------------------- - -The procedure to execute the ACS test cases on the RD-N1-Edge platform is listed -below. - - :: - - cd model-scripts/rdinfra - ./acs.sh -p rdn1edge -v <path to luv-live image> -n [true|false] -a <additional_params> - - -Supported command line options are listed below - - - -v <absolute path to the luv-live prebuilt image> - - - Allows use of a pre-built luv-live image for the test. The absolute - path to the luv-live image has be supplied as the parameter. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> (optional) - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to execute the ACS tests are as listed below. - - - :: - - ./acs.sh -p rdn1edge -v /tmp/luv-live-image-gpt.img - - - This command starts the execution of the RD-N1-Edge model and the ACS - tests are executed. The luv-live image is picked up from the location - ./tmp/luv-live-image-gpt.img. - - - :: - - ./acs.sh -p rdn1edge -n true -v /tmp/luv-live-image-gpt.img -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the RD-N1-Edge model with - networking enable and the ACS tests are executed. The luv-live image is - picked up from the location /tmp/luv-live-image-gpt.img. Additional - parameters to the model are supplied using the -a command line parameter. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rdn1edge/how-to/busybox-boot.rst b/docs/rdn1edge/how-to/busybox-boot.rst deleted file mode 100644 index 29de818..0000000 --- a/docs/rdn1edge/how-to/busybox-boot.rst +++ /dev/null @@ -1,152 +0,0 @@ -How to build RD-N1-Edge and RD-N1-Edge-Dual platform software to validate busybox boot -====================================================================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - -Busybox boot on RD-N1-Edge and RD-N1-Edge-Dual platform -------------------------------------------------------- - -Busybox is a lightweight executable which packages lots of POSIX compliant UNIX -utilities in a single file system. The busybox boot test on RD-N1-Edge and -RD-N1-Edge-Dual platform ensures that the software stack which runs on the model -is able to boot a Linux operating system with a busybox filesystem. - -Boot test is especially helpful when porting the software stack for new -platforms which are derivative of the RD-N1-Edge or RD-N1-Edge-Dual as this test -can be quickly executed to ensure that the various software components are -properly integrated and verify the basic functionality of various software -components. As part of this test, the following components of the software stack -are built - *TF-A*, *UEFI*, *Linux*, *GRUB*, *SCP*. - -This document describes how to build and execute the boot test on the -*RD-N1-Edge* and *RD-N1-Edge-Dual* fastmodel. - -Procedure to build Busybox boot test for RD-N1-Edge and RD-N1-Edge-Dual platform --------------------------------------------------------------------------------- - -This section describes how to build the disk image for busybox boot test. The -disk image consists of an EFI partition which has grub and an ext3 partition -which has the linux kernel image. Examples on how to use the build command for -busybox boot test are listed below. - -To build the software stack, the command to be used is - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p <platform> <command> - -Supported command line options are listed below - - - <platform> - - - Supported platforms are - - - ``rdn1edge`` for RD-N1-Edge - - ``rdn1edgex2`` for RD-N1-Edge-Dual - - - <command> - - - Supported commands are - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p rdn1edge all - - - This command cleans, builds and packages the software stack needed - for the busybox boot test on RD-N1-Edge platform. - - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p rdn1edgex2 build - - - This command performs an incremental build of the software components - included in the software stack for the RD-N1-Edge-Dual platform. Note: - this command should be followed by the 'package' command to complete the - preparation of the FIP and the disk image. - - - :: - - ./build-scripts/rdinfra/build-test-busybox.sh -p rdn1edge package - - - This command packages the previously built software stack and prepares - the FIP and the disk image. - -Procedure for validating Busybox boot test for RD-N1-Edge and RD-N1-Edge-Dual platforms ---------------------------------------------------------------------------------------- - -After the build for busybox boot test is complete, the following command starts -the execution of the *RD-N1-Edge* or *RD-N1-Edge-Dual* fastmodel and the -software boots up to the busybox prompt. Examples on how to use the command are -listed below. - -To boot up to the busybox prompt, the command to be used is - - :: - - cd model-scripts/rdinfra - ./boot.sh -p <platform> -a <additional_params> -n [true|false] - - -Supported command line options are listed below - - - -p <platform> - - - Specifies the platform to build. Supported platforms are - - - ``rdn1edge`` for RD-N1-Edge - - ``rdn1edgex2`` for RD-N1-Edge-Dual - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the Boot test are as listed below. - - - :: - - ./boot.sh -p rdn1edgex2 - - - This command starts the execution of the RD-N1-Edge-Dual model and the - software boots up to the Busybox prompt. - - - :: - - ./boot.sh -p rdn1edge -n true - - - This command starts the execution of the RD-N1-Edge model and the - software boots up to the Busybox prompt. The model supports - networking allowing the software running within the model to access - the network. - - - :: - - ./boot.sh -p rdn1edge -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the RD-N1-Edge model with - networking enabled and the software boots up to the Busybox prompt. - Additional parameters to the model are supplied using the -a command - line parameter. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rdn1edge/how-to/create-tap-interface.rst b/docs/rdn1edge/how-to/create-tap-interface.rst deleted file mode 100644 index f26b9df..0000000 --- a/docs/rdn1edge/how-to/create-tap-interface.rst +++ /dev/null @@ -1,59 +0,0 @@ -How to create tap interface to enable networking for FVPs -========================================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Context -------- - -RD-N1-Edge fast model supports virtual networking and it can interface with the -host PC network through the tap interface setup on the host machine. The steps -to setup a TAP interface on the host PC are listed below. This requires Ubuntu -16.04 or Ubuntu 18.04 as the host PC. - - -How to setup tap interface --------------------------- - -- Install the ``bridge-utils`` package - - :: - - sudo apt-get install bridge-utils - -- The first step is to create a bridge and add the host PC network as its - interface. Here, ``br0`` is the bridge name and ``enp0s3`` is the host PC - network device name. Replace these names with the names of the interfaces - used on the host PC. - - :: - - sudo brctl addbr br0 - sudo brctl addif br0 enp0s3 - sudo ifconfig enp0s3 0.0.0.0 - sudo ifconfig br0 up - sudo dhclient br0 - -- Next setup is to add the tap interface. Here, ``tap0`` is the name of the tap - interface. - - :: - - sudo ip tuntap add dev tap0 mode tap user $(whoami) - sudo ifconfig tap0 0.0.0.0 promisc up - sudo brctl addif br0 tap0 - -Note: These steps do not make a persistent instance of the bridge and the tap -interface. After the host PC reboots, these steps have to be repeated again. - -Refer `this documentation <https://wiki.linuxfoundation.org/networking/bridge>`_ -for more details. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rdn1edge/how-to/debian-test.rst b/docs/rdn1edge/how-to/debian-test.rst deleted file mode 100644 index e01c3f8..0000000 --- a/docs/rdn1edge/how-to/debian-test.rst +++ /dev/null @@ -1,223 +0,0 @@ -How to build RD-N1-Edge platform software to install and boot Debian distribution -================================================================================= - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Debian distribution boot support --------------------------------- -RD-N1-Edge software stack supports the installation and boot of Debian 9.8 -Stretch Distribution (Debian 9.8 Distribution). The Debian distribution is -installed on a SATA disk and the installed image can be used for multiple boots. - - -Procedure to build RD-N1-Edge software stack for debian boot ------------------------------------------------------------- - -The RD-N1-Edge platform software stack has to be first built to prepare for the -debian distribution installation step. The procedure to execute the RD-N1-Edge -platform stack is listed below. - -To build the RD-N1-Edge software stack, the command to be used is - - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge <command> - - - Supported command line options are listed below - - - <command> - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -An example of the command to begin the installation of the debian distribution -is listed below. - - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge all - - - This command cleans, builds and packages the RD-N1-Edge software stack - needed for the Debian installation/boot test for RD-N1-Edge platform. - - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge build - - - This command performs an incremental build of the software components - included in the software stack for the RD-N1-Edge platform. Note: this - command should be followed by the ``package`` command to complete the - preparation of the FIP image. - - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge package - - - This command packages the previously built software stack and prepares - the FIP image. - - -Procedure for installing Debian distro on RD-N1-Edge platform -------------------------------------------------------------- - -After the build for the distro is complete, Debian can be installed into a -SATA disk image. Before beginning the installation process download the iso -image of the required debian version. For example, Debian 9.8 Strech CD ISO -image can be downloaded from `here <https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/>`_ -or with this `direct link <https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/debian-9.8.0-arm64-xfce-CD-1.iso>`_. - -The command used to begin the distro installation is: - - :: - - cd model-scripts/rdinfra - ./distro.sh -p rdn1edge -i <iso_image_path> -s <disk size> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -i <iso_image_path> - - - Path to the downloaded installer iso image. - - - -s <disk_size> - - - Size of the SATA disk image (in GB) to be created. 4GB and above is - good enough for most use cases. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -An example of the command to begin the boot of the debian distribution is -listed below. - - - :: - - ./distro.sh -p rdn1edge -i ./debian-9.8.0-arm64-xfce-CD-1.iso -s 4 - - - This command creates a 4GB SATA disk image, boots the RD-N1-Edge - software stack and start the installation of debian distro. - - - The RD-N1-Edge platform supports a total of 8GB of DDR memory out of - which 6GB of memory is located above the 32-bit memory space. The debian - installation fails if the upper 6GB is enabled. To disable the use of - the upper 6GB, at the grub menu displayed during the installation, - edit the kernel boot parameters as below for enabling earlycon output - and limiting the DDR memory to 2032MB (2GB - 16MB) for SATA disk - detection. - - :: - - setparams 'Install' - set background_color=black - linux /install.a64/vmlinuz mem=2032M earlycon=pl011,0x7ff80000 console=ttyAMA0,115200 - initrd /intsall.a64/initrd.gz - - - From here on, follow the instructions of the Debian installer. For more - information about the installation procedure, please refer this - `link <https://www.debian.org/releases/stable/arm64/index.html.en>`_. - - - During installation, the installer will prompt the user with the message - 'Load CD-ROM drivers from removable media' and display two options - - Yes/No. - - - Select the option 'No' which would again display two options - - Yes/No. - - Select the option 'Yes' which will display 'Automatic detection - did not find CD-ROM'. - - Module needed for accessing CD-ROM and display two options - - - none - - cdrom - - - Select the option 'none' and enter ``/dev/vda``. The installation - media on the virtio disk will be detected and installation - continues. - - - After the installation is completed, the disk image with a random name - "<number>.satadisk" will be created in model-scripts/rdinfra/ folder. - User should use this disk image when booting the Debian distribution. - - -Procedure for booting Debian distro on RD-N1-Edge platform ----------------------------------------------------------- - -To boot the debian distro, use the following command: - - :: - - cd model-scripts/rdinfra - ./distro.sh -p rdn1edge -d <satadisk_path> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -d <satadisk_path> - - - Path to the installed SATA disk image created using the previous - section. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands are as listed below. - - - :: - - ./distro.sh -p rdn1edge - - - This command looks for the available .satadisk image in the - ``model-scripts/rdinfra`` folder and boots with that image. If multiple - .satadisk images are found, it will list them all but won't boot. - - - :: - - ./distro.sh -p rdn1edge -d ./debian.satadisk - - - This command begins the distro boot from the ``debian.satadisk`` image. - - - During boot, at the grub menu, edit the kernel boot parameters as below for - enabling earlycon output and limiting the DDR memory to 2032MB for - SATA disk detection - - :: - - setparams 'Install' - set background_color=black - linux /install.a64/vmlinuz mem=2032M earlycon=pl011,0x7ff80000 console=ttyAMA0,115200 - initrd /intsall.a64/initrd.gz - - Save and exit the grub menu. The boot will then continue up to the login - prompt. - - -This completes the validation of the Debian distribution installation and boot -functionalities. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rdn1edge/how-to/fedora-test.rst b/docs/rdn1edge/how-to/fedora-test.rst deleted file mode 100644 index a9cde53..0000000 --- a/docs/rdn1edge/how-to/fedora-test.rst +++ /dev/null @@ -1,177 +0,0 @@ -How to build RD-N1-Edge platform software to install and boot Fedora distribution
-=================================================================================
-
-.. section-numbering::
- :suffix: .
-
-.. contents::
-
-
-Fedora distribution boot support
---------------------------------
-RD-N1-Edge software stack supports the installation and boot of Fedora Enterprise
-Server Distribution (Fedora 27 Distribution). The Fedora distribution is
-installed on a SATA disk and the installed image can be used for multiple boots.
-
-
-Procedure to build RD-N1-Edge software stack for Fedora boot
-------------------------------------------------------------
-
-The RD-N1-Edge platform software stack has to be first built to prepare for the
-Fedora distribution installation step. The procedure to execute the RD-N1-Edge
-platform stack is listed below.
-
-To build the RD-N1-Edge software stack, the command to be used is
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rdn1edge <command>
-
- - Supported command line options are listed below
-
- - <command>
-
- - ``clean``
- - ``build``
- - ``package``
- - ``all`` (all the three above)
-
-
-An example of the command to begin the installation of the Fedora distribution
-is listed below.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rdn1edge all
-
- - This command cleans, builds and packages the RD-N1-Edge software stack
- needed for the Fedora installation/boot test for RD-N1-Edge platform.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rdn1edge build
-
- - This command performs an incremental build of the software components
- included in the software stack for the RD-N1-Edge platform. Note: this
- command should be followed by the ``package`` command to complete the
- preparation of the fip image.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rdn1edge package
-
- - This command packages the previously build software stack and prepares
- the fip image.
-
-
-Procedure for installing Fedora distro on RD-N1-Edge platform
--------------------------------------------------------------
-
-After the build for the distro is complete, Fedora can be installed into a
-SATA disk image. Before beginning the installation process download the iso
-image of the required Fedora version. For example, the Fedora distribution iso image
-has to be downloaded from `here <https://dl.fedoraproject.org/pub/fedora-secondary/releases/27/Server/aarch64/iso/>`_
-or with this `direct link <https://dl.fedoraproject.org/pub/fedora-secondary/releases/27/Server/aarch64/iso/Fedora-Server-dvd-aarch64-27-1.6.iso>`_.
-
-The command used to begin the distro installation is:
-
- ::
-
- cd model-scripts/rdinfra
- ./distro.sh -p rdn1edge -i <iso_image_path> -s <disk size> -a <additional_params> -n [true|false]
-
-Supported command line options are listed below
-
- - -i <iso_image_path>
-
- - Path to the downloaded installer iso image.
-
- - -s <disk_size>
-
- - Size of the SATA disk image (in GB) to be created. 4GB and above is
- good enough for most use cases.
-
- - -n [true|false] (optional)
-
- - Controls the use of network ports by the model. If network ports have
- to be enabled, use 'true' as the option. Default value is set to
- 'false'.
-
- - -a <additional_params>
-
- - Specify any additional model parameters to be passed. The model
- parameters and the data to be passed to those parameters can be found
- in the FVP documentation.
-
-
-An example of the command to begin the boot of the Fedora distribution is
-listed below.
-
- - ::
-
- ./distro.sh -p rdn1edge -i ./Fedora-Server-dvd-aarch64-27-1.6.iso -s 4
-
- - This command creates a 4GB SATA disk image, boot the RD-N1-Edge software
- stack and start the installation of Fedora distro.
-
- - From here on, follow the instructions of the Fedora installer. For more
- information about the installation procedure, please refer this
- `link <https://docs.fedoraproject.org/en-US/index.html>`_.
-
- - After the installation is completed, the disk image with a random name
- "<number>.satadisk" will be created in model-scripts/rdinfra/ folder. User
- should use this disk image when booting the Fedora distribution.
-
-
-Procedure for booting Fedora distro on RD-N1-Edge platform
-----------------------------------------------------------
-
-To boot the Fedora distro, use the following command:
-
- ::
-
- cd model-scripts/rdinfra
- ./distro.sh -p rdn1edge -d <satadisk_path> -a <additional_params> -n [true|false]
-
-Supported command line options are listed below
-
- - -d <satadisk_path>
-
- - Path to the installed SATA disk image created using the previous
- section.
-
- - -n [true|false] (optional)
-
- - Controls the use of network ports by the model. If network ports have
- to be enabled, use 'true' as the option. Default value is set to
- 'false'.
-
- - -a <additional_params>
-
- - Specify any additional model parameters to be passed. The model
- parameters and the data to be passed to those parameters can be found
- in the FVP documentation.
-
-
-Example command functionality are as listed below.
-
- - ::
-
- ./distro.sh -p rdn1edge
-
- - This command looks for the available .satadisk image in the
- ``model-scripts/rdinfra`` folder and boots with that image. If multiple
- .satadisk images are found, it will list them all but won't boot.
-
- - ::
-
- ./distro.sh -p rdn1edge -d ./fedora.satadisk
-
- - This command begins the distro boot from the ``fedora.satadisk`` image.
-
-This completes the validation of the Fedora distribution installation and boot
-functionalities.
-
---------------
-
-*Copyright (c) 2019, Arm Limited. All rights reserved.*
diff --git a/docs/rdn1edge/how-to/kvm-test.rst b/docs/rdn1edge/how-to/kvm-test.rst deleted file mode 100644 index 7e5ad00..0000000 --- a/docs/rdn1edge/how-to/kvm-test.rst +++ /dev/null @@ -1,188 +0,0 @@ -How to build RD-N1-Edge platform software to validate KVM feature -================================================================= - -.. section-numbering:: - :suffix: . - -.. contents:: - -What is KVM ------------ - -Kernel Virtual Machine (KVM) is a virtualization module built in the linux -kernel which lets the user to turn linux into a hypervisor to allow hosting -single/multiple isolated guests or virtual machine. KVM requires a processor -with hardware virtualization extensions. - -Currently, KVM is part of linux kernel. Some of the features of KVM are: - -- Over-committing : KVM allows to allocate more virtualized CPU or memory - for the virtual machine than that of the host. -- Thin provisioning : KVM allows to allocate and optimize the flexible - storage for the virtual machines. -- Disk throttling : KVM allows to set limits for disk I/O requests. -- Virtual CPU hot plug: KVM allows ability to increase the CPU count of the - virtual machine during run time. - - -What does KVM test on RD-N1-Edge demonstrate --------------------------------------------- - -The RD-N1-Edge platform demonstrates boot up 2+ instances of guest OS's using -`lvkm tool <https://github.com/lkvm/lkvm>`_. Linux KVM tool supports booting -guest OS's of the same architecture. For RD-N1-Edge booting only ARM based -virtual machine is supported. KVM test for RD-N1-Edge demonstrates booting -Linux Kernel v4.18 or Linux Kernel v4.13 as guest with Linux Kernel v4.18 as -the host. - - -Procedure to build KVM test for RD-N1-Edge platform ---------------------------------------------------- - -Execution of the KVM test requires booting a Fedora distribution system with the -kernel built for the RD-N1-Edge platform. The first step would be to -get a `installed Fedora distribution`_ satadisk image and `prepare the image`_. -After the Fedora satadisk image has been prepared, the ``fedora.satadisk`` image -file has to be placed in the ``prebuilts/refinfra`` directory. Now, build the -firmware components and the kernel image needed for running the KVM test. For -generation of these image, the build command to be used is listed below. - -To build the RD-N1-Edge software stack, the following command can be used - - :: - - ./build-scripts/rdinfra/build-test-kvm.sh -p rdn1edge <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/rdinfra/build-test-kvm.sh -p rdn1edge all - - - This command cleans, builds and packages the software stack needed - for the KVM test for RD-N1-Edge platform. - - - :: - - ./build-scripts/rdinfra/build-test-kvm.sh -p rdn1edge build - - - This command performs an incremental build of the software components - included in the software stack for the RD-N1-Edge platform. Note: this - command should be followed by the 'package' command to complete the - preparation of the FIP and the disk image. - - - :: - - ./build-scripts/rdinfra/build-test-kvm.sh -p rdn1edge package - - - This command packages the previously built software stack and prepares - the FIP and loads the kernel into the disk image. - - -Procedure for validating KVM test for RD-N1-Edge platform ---------------------------------------------------------- - -After the build for the KVM test is complete, to boot up to the Fedora login -prompt using the software stack, the command to be used is - - :: - - cd model-scripts/rdinfra - ./kvm.sh -p rdn1edge -a <additional_params> -n [true|false] - -Note: ``fedora.satadisk`` is expected at the location ``prebuilts/refinfra`` for -this command to work. - -Supported command line options are listed below - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the KVM functionality are as listed below. - - - :: - - ./kvm.sh -p rdn1edge - - - This command starts the execution of the RD-N1-Edge model and the - software boots up to the Fedora login prompt. - - - :: - - ./kvm.sh -p rdn1edge -n true - - - This command starts the execution of the RD-N1-Edge model and the - software boots up to the Fedora login prompt. The model supports - networking allowing the software running within the model to access - the network. - - - :: - - ./kvm.sh -p rdn1edge -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the RD-N1-Edge model with - networking enabled and the software boots up to the Fedora login prompt. - Additional parameters to the model are supplied using the -a command - line parameter. - - -During the system boot, select the 'Fedora (refinfra) 27 (Server Edition)' -kernel on the grub menu. After the boot is complete, login as the root user. - - - IMPORTANT: In the ``/root/`` directory, the lkvm executable is made - available as part of the `prepare fedora disk process`_. Before using - the lkvm tool, two dependencies (``glibc-static`` and ``libfdt-devel``) - need to be installed using the ``yum`` tool. This requires - `tap interface setup on the host`_ and the network parameter (``-n``) set - to be true while starting the test. Enabling the network interface allows - to model to connect to the internet through the network bridge interface - of the host PC. The command to install the dependencies for ``lkvm`` is: - - - :: - - yum install -y glibc-static libfdt-devel - - - After the dependencies are installed, kvm test can be done using the - following command: - - - :: - - ./lkvm run -k <path-to-linux-image> -c 8 --irqchip gicv3 -p "console=ttyS0,115200 earlycon=uart,mmio,0x3f8 debug" - - - For example to run the kernel on the kvm, following command can be used: - - :: - - ./lkvm run -k /boot/vmlinux-refinfra -c 8 --irqchip gicv3 -p "console=ttyS0,115200 earlycon=uart,mmio,0x3f8 debug" - -This completes the validation of the KVM functionality. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - -.. _installed Fedora distribution: fedora-test.rst -.. _prepare the image: prepare-fedora-disk.rst -.. _prepare fedora disk process: prepare-fedora-disk.rst -.. _tap interface setup on the host: create-tap-interface.rst diff --git a/docs/rdn1edge/how-to/prepare-fedora-disk.rst b/docs/rdn1edge/how-to/prepare-fedora-disk.rst deleted file mode 100644 index ddeb399..0000000 --- a/docs/rdn1edge/how-to/prepare-fedora-disk.rst +++ /dev/null @@ -1,43 +0,0 @@ -How to prepare a fedora disk image for RAS and KVM test -======================================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Why to prepare the fedora disk image ------------------------------------- - -The RAS and KVM tests on the RD-N1-Edge platform requires a Fedora enterprise -linux as the root filesystem. The build and run scripts for these tests -require a pre-installed disk image of Fedora 27 to be present in the -prebuilts/refinfra directory. This pre-installed disk image can then be -preloaded with all the tools required to validate the KVM and RAS tests. - -Preparing the fedora disk image -------------------------------- - -- Install a Fedora 27 Enterprise Linux distribution disk image. Refer to - [refer] for detailed instructions on this. - -- Create the directory ``prebuilts/refinfra`` (if that does not exist) at the - root of the workspace. - -- Copy the installed fedora disk image at ``prebuilts/refinfra/fedora.satadisk`` - -- Use the following command to update the grub menu, download/unpack/load the - lvkm executable to the /root/ directory of the fedora disk. - Note: sudo permission is required for completing this step. - - :: - - sudo ./build-scripts/rdinfra/prepare-fedora-disk.sh - -This completes the procedure to prepare the fedora disk image. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rdn1edge/how-to/ras-test.rst b/docs/rdn1edge/how-to/ras-test.rst deleted file mode 100644 index 32dbefa..0000000 --- a/docs/rdn1edge/how-to/ras-test.rst +++ /dev/null @@ -1,194 +0,0 @@ -How to build RD-N1-Edge platform software to validate platform RAS error handling -================================================================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - -What is RAS ------------ - -Reliability Availability and Serviceability are three aspects that are -considered to be vital to ensure correct functioning of a server system. These -require extensive support in the platform hardware and software to ensure that -the system is producing correct results and that in a scenario where the system -encounters a malfunctioning component, the system is able to: - - - identify and correct the error condition - - record and flag errors to an external component like a Board Management - Controller (BMC) - - provide for mechanisms to avoid or keep to a minimum, the system downtime - by supporting features like hot-swapping of failing components, or by - providing for redundancy in the system hardware. - -What does RAS test on RD-N1-Edge demonstrate --------------------------------------------- - -The RD-N1-Edge platform supports multiple RAS error sources. Out of these, the -RAS error handling test validates the DMC-620 single-bit RAS error injection and -error handling of features in the platform software. The RAS error injection and -error handling requires multiple software components (kernel and firmware -components) to work in tandem in order for the RAS errors to be detected and -propogated to the kernel. This RAS test demonstrates the error injection and -error handling of the DMC-620 single-bit RAS error. - -Procedure to build RAS test for RD-N1-Edge platform ---------------------------------------------------- - -The RD-N1-Edge platform demonstrates the RAS feature by injecting a memory error -using RAS simulation capabilities in the DMC-620 controller. The RAS support -consists of the following components: - -- The DMC RAS driver. The driver executes as part of the S-EL0 Management Mode - and provides DMC RAS error handling and reporting. -- The TF-A SPM and SDEI modules which are responsible for handling system - interrupts and sending notifications to the DMC RAS driver and the Linux - kernel. -- APEI driver used to retrieve the system RAS errors from S-EL0 Management mode - code. This information is then used to populate the HEST ACPI table, for - future consumption by the Linux kernel. -- CPER Library which is used by individual RAS error handling drivers to - populate the CPER record with relevant data, to be passed on to the Linux - kernel on the non-secure side. -- The Linux kernel SDEI client which is part of the kernel ACPI APEI - notification mechanism. - -Execution of the RAS test requires booting a Fedora distribution system with the -kernel containing changes needed for the RAS test. The first step would be to -get a installed Fedora distribution satadisk image. After the Fedora SATA disk -image has been prepared, the Fedora.satadisk image file is created under the -prebuilts/refinfra directory. Now, build the firmware components and the kernel -image needed for running the RAS test. For generation of these image, the build -command to be used is listed below. - -To build the RD-N1-Edge software stack, the command to be used is - - :: - - ./build-scripts/rdinfra/build-test-ras.sh -p rdn1edge <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/rdinfra/build-test-ras.sh -p rdn1edge all - - - This command cleans, builds and packages the RD-N1-Edge software stack - needed for the RAS test for RD-N1-Edge platform. - - - :: - - ./build-scripts/rdinfra/build-test-ras.sh -p rdn1edge build - - - This command performs an incremental build of the software components - included in the software stack for the RD-N1-Edge platform. Note: this - command should be followed by the 'package' command to complete the - preparation of the fip and the disk image. - - - :: - - ./build-scripts/rdinfra/build-test-ras.sh -p rdn1edge package - - - This command packages the previously build software stack and prepares - the fip and the disk image. - -Procedure for validating RAS test for RD-N1-Edge platform ---------------------------------------------------------- - -After the build for the RAS test is complete, to boot upto the Fedora login -prompt using the RD-N1-Edge software stack, the command to be used is - - :: - - cd model-scripts/rdinfra - ./ras.sh -p rdn1edge -n [true|false] -a <additional_params> - - -Supported command line options are listed below - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> (optional) - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the RAS functionality are as listed below. - - - :: - - ./ras.sh -p rdn1edge - - - This command starts the execution of the RD-N1-Edge model and the - software boots upto the Fedora login prompt. - - - :: - - ./ras.sh -p rdn1edge -n true - - - This command starts the execution of the RD-N1-Edge model and the - software boots upto the Fedora login prompt. The model supports - networking allowing the software running within the model to access the - network. - - - :: - - ./ras.sh -p rdn1edge -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the RD-N1-Edge model with - networking enabled and the software boots upto the Fedora login - prompt. Additional parameters to the model are supplied using the -a - command line parameter. - - -During the system boot, select the 'Fedora (refinfra) 27 (Server Edition)' -kernel on the grub menu. On a successful login into Fedora, execute the -following command on the Fedora shell prompt to inject the DMC-620 single-bit -RAS error. - - :: - - 'echo 0x123 > /sys/kernel/debug/sdei_ras_poison' - -On execution of this command, the error record dump, known as CPER dump would be -seen on the Fedora terminal's console, similar to the sample dump shown below. - - :: - - [115792.848999] ghes_edac: Internal error: Can't find EDAC structure - [115792.849003] [Firmware Warn]: GHES: Invalid address in generic error data: 0x1f03fedcd - [115792.849008] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 - [115792.849013] {1}[Hardware Error]: event severity: recoverable - [115792.849017] {1}[Hardware Error]: Error 0, type: corrected - [115792.849021] {1}[Hardware Error]: fru_id: 00000000-0000-0000-0000-000000000000 - [115792.849025] {1}[Hardware Error]: fru_text: - [115792.849029] {1}[Hardware Error]: section_type: memory error - [115792.849033] {1}[Hardware Error]: physical_address: 0x00000001f03fedcd - [115792.849038] {1}[Hardware Error]: physical_address_mask: 0xfffffffffffff000 - [115792.849042] {1}[Hardware Error]: error_type: 8, parity error - -This completes the validation of the RAS functionality. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rdn1edge/how-to/redhat-test.rst b/docs/rdn1edge/how-to/redhat-test.rst deleted file mode 100644 index eea258a..0000000 --- a/docs/rdn1edge/how-to/redhat-test.rst +++ /dev/null @@ -1,175 +0,0 @@ -How to build RD-N1-Edge platform software to install and boot Red Hat distribution
-==================================================================================
-
-.. section-numbering::
- :suffix: .
-
-.. contents::
-
-
-Red Hat distribution boot support
----------------------------------
-RD-N1-Edge software stack supports the installation and boot of Red Hat Enterprise
-Server Distribution (RHEL 7.4 Distribution). The Red Hat distribution is
-installed on a SATA disk and the installed image can be used for multiple boots.
-
-
-Procedure to build RD-N1-Edge software stack for Red Hat boot
--------------------------------------------------------------
-
-The RD-N1-Edge platform software stack has to be first built to prepare for the
-Red Hat distribution installation step. The procedure to execute the RD-N1-Edge
-platform stack is listed below.
-
-To build the RD-N1-Edge software stack, the command to be used is
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rdn1edge <command>
-
- - Supported command line options are listed below
-
- - <command>
-
- - ``clean``
- - ``build``
- - ``package``
- - ``all`` (all the three above)
-
-
-An example of the command to begin the installation of the Red Hat distribution
-is listed below.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rdn1edge all
-
- - This command cleans, builds and packages the RD-N1-Edge software stack
- needed for the Red Hat installation/boot test for RD-N1-Edge platform.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rdn1edge build
-
- - This command performs an incremental build of the software components
- included in the software stack for the RD-N1-Edge platform. Note: this
- command should be followed by the ``package`` command to complete the
- preparation of the fip image.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p rdn1edge package
-
- - This command packages the previously build software stack and prepares
- the fip image.
-
-
-Procedure for installing Red Hat distro on RD-N1-Edge platform
---------------------------------------------------------------
-
-After the build for the distro is complete, Red Hat can be installed into a
-SATA disk image. Before beginning the installation process, contact Red Hat to
-obtain the RHEL 7.4 DVD installer image for AArch64 platform.
-
-The command used to begin the distro installation is:
-
- ::
-
- cd model-scripts/rdinfra
- ./distro.sh -p rdn1edge -i <iso_image_path> -s <disk size> -a <additional_params> -n [true|false]
-
-Supported command line options are listed below
-
- - -i <iso_image_path>
-
- - Path to the downloaded installer iso image.
-
- - -s <disk_size>
-
- - Size of the SATA disk image (in GB) to be created. 4GB and above is
- good enough for most use cases.
-
- - -n [true|false] (optional)
-
- - Controls the use of network ports by the model. If network ports have
- to be enabled, use 'true' as the option. Default value is set to
- 'false'.
-
- - -a <additional_params>
-
- - Specify any additional model parameters to be passed. The model
- parameters and the data to be passed to those parameters can be found
- in the FVP documentation.
-
-
-An example of the command to begin the boot of the Red Hat distribution is
-listed below.
-
- - ::
-
- ./distro.sh -p rdn1edge -i ./RHEL-ALT-7.4-20171030.0-Server-aarch64-dvd1.iso -s 4
-
- - This command creates a 4GB SATA disk image, boot the RD-N1-Edge software
- stack and start the installation of Red Hat distro.
-
- - From here on, follow the instructions of the Red Hat installer. For more
- information about the installation procedure, please refer this
- `link <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/>`_.
-
- - After the installation is completed, the disk image with a random name
- "<number>.satadisk" will be created in model-scripts/rdinfra/ folder. User
- should use this disk image when booting the Red Hat distribution.
-
-
-Procedure for booting Red Hat distro on RD-N1-Edge platform
------------------------------------------------------------
-
-To boot the Red Hat distro, use the following command:
-
- ::
-
- cd model-scripts/rdinfra
- ./distro.sh -p rdn1edge -d <satadisk_path> -a <additional_params> -n [true|false]
-
-Supported command line options are listed below
-
- - -d <satadisk_path>
-
- - Path to the installed SATA disk image created using the previous
- section.
-
- - -n [true|false] (optional)
-
- - Controls the use of network ports by the model. If network ports have
- to be enabled, use 'true' as the option. Default value is set to
- 'false'.
-
- - -a <additional_params>
-
- - Specify any additional model parameters to be passed. The model
- parameters and the data to be passed to those parameters can be found
- in the FVP documentation.
-
-
-Example command functionality are as listed below.
-
- - ::
-
- ./distro.sh -p rdn1edge
-
- - This command looks for the available .satadisk image in the
- ``model-scripts/rdinfra`` folder and boots with that image. If multiple
- .satadisk images are found, it will list them all but won't boot.
-
- - ::
-
- ./distro.sh -p rdn1edge -d ./redhat.satadisk
-
- - This command begins the distro boot from the ``redhat.satadisk`` image.
-
-This completes the validation of the Red Hat distribution installation and boot
-functionalities.
-
---------------
-
-*Copyright (c) 2019, Arm Limited. All rights reserved.*
diff --git a/docs/rdn1edge/how-to/secureboot-test.rst b/docs/rdn1edge/how-to/secureboot-test.rst deleted file mode 100644 index 118d7c0..0000000 --- a/docs/rdn1edge/how-to/secureboot-test.rst +++ /dev/null @@ -1,222 +0,0 @@ -How to build RD-N1-Edge platform software to validate Secure Boot -================================================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - -What is Secure Boot -------------------- - -Secure boot is a mechanism to build and maintain a complete chain of trust on -all the software layers executed in a system and preventing malicious code to be -stored and loaded in place of the authenticated one. When the device starts, the -firmware checks the signature of each piece of boot software, including UEFI -firmware drivers, EFI applications, and the operating system. If the signatures -are valid, the device boots, and the firmware gives control to the operating -system. Fundamental to the success of the secure boot is the ability to securely -store (also referred to as secure storage) and access the keys used for -authentication during the various stages of boot. - -Secure boot and Secure storage mechanisms are defined by the UEFI -specifications. In short, the UEFI specifications define the use of two -asymmetric key pairs, platform key (PK) and Key Exchange Key (KEK), and -databases for valid and black listed signatures. These keys and databases are -used during the secure boot phase which implies that the platform should provide -a tamper proof mechanism to store these keys. - -Secure boot support for RD-N1-Edge platform -------------------------------------------- - -The RD-N1-Edge platform software allows validation of the secure boot process. -Though secure boot process have to be validated using a linux distribution as -the target OS, the RD-N1-Edge platform software stack currently limits this feature -validation to boot of a signed busybox OS. There are pre-requisite packages to -be installed on the host PC to build the disk image to validate the secure boot -process. It is important that the following packages are installed prior to -building of the software stack for secure boot validation. The prerequisite -package installer script, if used, does install these packages as well. - -- efitools git repo is cloned and available at tools/efitools -- sbsign package is installed on to the local host system - -The next step is to create key pairs required for secure boot. The one-time -generation of the following key pairs are mandatory - PK, KEK, DB and DBX. The -following commands can be used to generate these key pairs. - -- Key Pair Creation : PK, KEK, DB and DBX - - :: - - cd tools/efitools - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=PK/" -keyout PK.key -out PK.crt -days 3650 -nodes -sha256 - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=KEK/" -keyout KEK.key -out KEK.crt -days 3650 -nodes -sha256 - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=DB_Key/" -keyout DB.key -out DB.crt -days 3650 -nodes -sha256 - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=DBX_Key/" -keyout DBX.key -out DBX.crt -days 3650 -nodes -sha256 - -- Convert crt certificate to der format - - :: - - openssl x509 -in PK.crt -outform der -out PK.der - openssl x509 -in KEK.crt -outform der -out KEK.der - openssl x509 -in DB.crt -outform der -out DB.der - openssl x509 -in DBX.crt -outform der -out DBX.der - -The signing of the grub and linux images are performed as a part of build script -“build-secureboot.sh”. There is no explicit user action required to sign these -images. - -Procedure to build secure boot test for RD-N1-Edge platforms ------------------------------------------------------------- - -The procedure to build the secure boot test along with the RD-N1-Edge platform software -stack is listed below. - -To build the RD-N1-Edge software stack, the command to be used is - - :: - - ./build-scripts/rdinfra/build-test-secureboot.sh -p rdn1edge <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/rdinfra/build-test-secureboot.sh -p rdn1edge all - - - This command cleans, builds and packages the RD-N1-Edge software stack needed - for the secure boot test for RD-N1-Edge platform. - - - :: - - ./build-scripts/rdinfra/build-test-secureboot.sh -p rdn1edge build - - - This command performs an incremental build of the software components - included in the software stack for the RD-N1-Edge platform. Note: this - command should be followed by the 'package' command to complete the - preparation of the fip and the disk image. - - - :: - - ./build-scripts/rdinfra/build-test-secureboot.shh -p rdn1edge package - - - This command packages the previously built software stack and prepares - the fip and the disk image. - - -Procedure to execute secure boot test on RD-N1-Edge platforms -------------------------------------------------------------- -The procedure to execute the secure boot test on the RD-N1-Edge platform is listed -below. - - :: - - cd model-scripts/rdinfra - ./secure_boot.sh -p rdn1edge -a <additional_params> -n [true|false] - - -Supported command line options are listed below - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the secure boot functionality are as listed below. - - - :: - - ./secure_boot.sh -p rdn1edge - - - This command starts the execution of the RD-N1-Edge model and the software - boots upto the busybox login prompt. - - - :: - - ./secure_boot.sh -p rdn1edge -n true - - - This command starts the execution of the RD-N1-Edge model and the - software boots upto the busybox login prompt. The model supports - networking allowing the software running within the model to access - the network. - - - :: - - ./secure_boot.sh -p rdn1edge -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the RD-N1-Edge model with networking - enabled and the software boots upto the busybox login prompt. Additional - parameters to the model are supplied using the -a command line - parameter. - -There are additional steps to be performed on the first boot to setup the secure -boot process. These steps are listed below. Ensure that these steps are executed -on the very first boot for validating the secure boot. - -- Interrupt the boot at EDK2 by pressing escape key and dropping into the EDK2 - boot menu. -- Select Device Manger -> Secure Boot Configuration -> Secure Boot Mode → - choose Custom mode and then press enter. -- Select "Custom Secure Boot Options” and then press enter. -- Select “DBX Options” -> "Enroll Signature" then press enter → - "Enroll Signature Using File" and the press enter → Select “NO VOLUME LEBEL” - and then press enter. -- Select EFI and press enter -> select BOOT and press enter → now Select - “DBX.der” and press enter -> “Commit Changes and Exit”. -- Repeat steps “d” and “e” for “DB options” for “DB.der”. -- Repeat steps “d” and “e” for “KEK options” for “KEK.der”. -- Repeat steps “d” and “e” for “PK options” for “PK.der”. -- Press Escape and press F10 to save. Ensure that the “Current Secure Boot - State” is set as “Enabled”. -- Press Escape and select the “continue” option. -- Prompts the user to press the “Enter”. Press Enter key which then reboots the - system -- Make sure to close the model using “Cross Mark” of “Fast Models -Clark” - windows after this, if model does not close then press “ctrl-c” to close it. - -Relaunch the model again, the platform boots up to busybox login prompt with -secure boot enabled. If the authentication of the grub or the linux kernel -fails, the boot fails and the user is notified about the authentication failure. - -To confirm that the boot is indeed a secure boot, the linux kernel messages -can be looked up. The following messages would appear in the linux boot log in -case of a secure linux kernel boot. - - :: - - Loading driver at 0x000F5D26000 EntryPoint=0x000F6D0AF80 - Loading driver at 0x000F5D26000 EntryPoint=0x000F6D0AF80 - EFI stub: Booting Linux Kernel... - EFI stub: UEFI Secure Boot is enabled. - EFI stub: Using DTB from configuration table - EFI stub: Exiting boot services and installing virtual address map... - [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd060] - -This completes the validation of the Secure boot functionality. - --------------- - -*Copyright (c) 2019, Arm Limited and Contributors. All rights reserved.* diff --git a/docs/rdn1edge/how-to/setup-pxe-server.rst b/docs/rdn1edge/how-to/setup-pxe-server.rst deleted file mode 100644 index 32bf51a..0000000 --- a/docs/rdn1edge/how-to/setup-pxe-server.rst +++ /dev/null @@ -1,204 +0,0 @@ -How to setup PXE server on Ubuntu -================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Context -------- - -Preboot Execution Environment (PXE) boot is a standardized server-client -environment to boot an OS remotely through network. This allows multiple client -to install/boot OS remotely from a single server. All major distributions such -as Fedora, Ubuntu, Debian, Red Hat supports PXE boot. The virtio network device -available in the RD-N1-Edge platform can be leveraged to do PXE boot of linux -distributions. Ubuntu in particular allows installation through CDROM or PXE -only. To install Ubuntu on RD-N1-Edge Platform, PXE boot should be used. - -How to setup TFTP server ------------------------- - -Before beginning the installation, on the host PC (sever), TFTP, apache2 and -DHCP servers must be setup. The following steps can be used as reference to -setup the PXE server. - -- Download the required linux distribution network installer for arm64 - architecture. For example, the Ubuntu network installer for arm64 can be - downloaded from `here <http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/current/images/netboot/netboot.tar.gz>`_. - -- Extract the downloaded tar files - - :: - - tar -xvzf netboot.tar.gz - -- Install the TFTP server, DHCP server and dependencies - - :: - - sudo apt-get install apache2 tftpd-hpa inetutils-inetd isc-dhcp-server - -- Configure the PXE server to point the tftpboot directory - - - Open ``/etc/default/tftpd-hpa`` to edit - - :: - - sudo vi /etc/default/tftpd-hpa - - - Append the following lines to the end - - :: - - RUN_DAEMON="yes" - OPTIONS="-l -s /var/lib/tftpboot" - - - Open ``/etc/inetd.conf`` file to edit - - :: - - sudo vi /etc/inetd.conf - - - Append the following line to the end - - :: - - tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot - -- Copy the installer files into the ``/var/lib/tftpboot`` folder - - :: - - sudo cp -fr <ubuntu-installer-path> /var/lib/tftpboot/ - -- Copy the installer files into the apache2 folder - - :: - - sudo mkdir /var/www/html/ubuntu - sudo cp -fr <ubuntu-installer-path> /var/www/html/ubuntu/ - -- Restart the TFTF server - - :: - - sudo systemctl restart tftpd-hpa - -- Check the status of the TFTP server to see if it is active - - :: - - sudo systemctl status tftpd-hpa - - - - If the status is displayed as ``Stopped``, try the following commands - to start the TFTP server again - - :: - - sudo /etc/init.d/inetutils-inetd stop - sudo systemctl restart tftpd-hpa - sudo systemctl status tftpd-hpa - sudo /etc/init.d/inetutils-inetd start - sudo systemctl status tftpd-hpa - -This completes the setup of the TFTP server. - - -How to setup DHCP server ------------------------- - -- Verify whether the DHCP server is stopped - - :: - - sudo systemctl status isc-dhcp-server - - - If the status is shown as ``Running``, the service can be stopped by - using the following command - - :: - - sudo systemctl stop isc-dhcp-server - -- Follow the instructions on `how to create tap interface`_ to setup the tap - interface in the host PC. - -- Configure the DHCP server to point the grub config file (assuming the PXE - server and DHCP server are running on the same PC) - - :: - - sudo vi /etc/dhcp/dhcpd.conf - - - Add the following lines at the end - - :: - - ddns-update-style none; - log-facility local7; - - default-lease-time 600; - max-lease-time 7200; - - authoritative; - allow booting; - allow bootp; - - subnet 192.168.130.0 netmask 255.255.255.0 { - option routers 192.168.130.1; - option subnet-mask 255.255.255.0; - option broadcast-address 192.168.130.255; - option domain-name-servers 10.118.10.61; - option ntp-servers time.nist.gov; - option netbios-name-servers 192.168.130.1; - option netbios-node-type 2; - default-lease-time 86400; - max-lease-time 86400; - range 192.168.130.100 192.168.130.150; - filename "ubuntu-installer/arm64/bootnetaa64.efi"; - } - group { - next-server 10.162.0.155; - host tftp { - filename "ubuntu-installer/arm64/bootnetaa64.efi"; - hardware ethernet 00:02:F7:EF:50:A0; # Check your ethernet mac address - fixed-address 10.162.0.157; - } - } - - -- Add the following lines at the end of ``/etc/default/isc-dhcp-server`` - - :: - - INTERFACES="br0" - INTERFACESv4="br0" - INTERFACESv6="" - -- Restart the DHCP server - - :: - - sudo systemctl restart isc-dhcp-server - - - Check the status of the DHCP server - - :: - - sudo systemctl status isc-dhcp-server - -This completes the PXE setup on the host PC side. Following this, linux -distribution installation can be done through the network. For example, refer -`how to install Ubuntu on RD-N1-Edge`_ for the complete installation steps. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - -.. _how to create tap interface: create-tap-interface.rst -.. _how to install Ubuntu on RD-N1-Edge: ubuntu-test.rst diff --git a/docs/rdn1edge/how-to/tftf-test.rst b/docs/rdn1edge/how-to/tftf-test.rst deleted file mode 100644 index d6f71e8..0000000 --- a/docs/rdn1edge/how-to/tftf-test.rst +++ /dev/null @@ -1,141 +0,0 @@ -How to build RD-N1-Edge platform software to execute TF-A Tests -=============================================================== - - -.. section-numbering:: - :suffix: . - -.. contents:: - -What are TF-A Tests -------------------- - -The Trusted Firmware-A Tests (TF-A Tests) is a suite of bare metal tests to -exercise the Trusted Firmware-A (TF-A) features from the normal world. -It enables strong TF-A functional testing without dependency on a rich OS. -It mainly interacts with TF-A through its SMC interface. It provides a basis -for TF-A developers to validate their own platform ports and add their own -test cases. - -TF-A Tests on RD-N1-Edge platform ---------------------------------- - -TF-A firmware on RD-N1-Edge platform has a significant importance in supporting -multiple features on the RD-N1-Edge platform. For instance, secure partition -manager component of TF-A is used in RAS and PSCI component is used for managing -idle states on the platform. There are many more important uses of TF-A in the -RD-N1-Edge platform software stack. So it becomes imperative that the RD-N1-Edge -platform implementation in TF-A is well tested. TF-A Tests on RD-N1-Edge -platform helps to serve this purpose. - -Tests to Skip -------------- - -The TF-A Test suite supports quite a lot of tests covering various aspects of -the TF-A platform implementation. It is possible to selectively disable the -tests that are not supported by listing those tests in the platform specific -``tests_to_skip.txt`` file. - -System suspend/resume related tests are not supported for RD-N1-Edge platform -as there are no wakeup sources in RD-N1-Edge FVP platforms. So such tests and -tests that fail are currently listed in the ``tests_to_skip.txt`` file and -listed below as well. - -- PSCI STAT/Stats test cases after system suspend -- PSCI System Suspend Validation -- PSCI SYSTEM SUSPEND stress tests - -Procedure to build TF-A Tests for RD-N1-Edge platform ------------------------------------------------------ - -The procedure to build the TF-A Test cases along with the RD-N1-Edge platform -software stack is listed below. The components of the RD-N1-Edge platform -software stack that are built is limited to those that provide the ability to -execute the TF-A Tests as a BL33 stage binary (i.e, SCP and TF-A). - -To build the software stack and TF-A Tests, the command to be used is - - :: - - ./build-scripts/build-test-tftf.sh -p rdn1edge <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/build-test-tftf.sh -p rdn1edge all - - - This command cleans, builds the required components of the RD-N1-Edge - platform software stack (SCP, TF-A) and TF-A Tests. It then prepares - the FIP image that can be used for executing the tests. - - - :: - - ./build-scripts/build-test-tftf.sh -p rdn1edge build - - - This command performs an incremental build of the required software - components in the software stack for the RD-N1-Edge platform and TF-A Tests. - Note: this command should be followed by the 'package' command to - complete the preparation of the FIP image. - - - :: - - ./build-scripts/build-test-tftf.sh -p rdn1edge package - - - This command packages the previously built software stack and prepares - the FIP image. - -Procedure to execute TF-A Tests for RD-N1-Edge platform -------------------------------------------------------- - -After the build for the TF-A Tests is complete to execute the TF-A Tests, the -command to be used is - - :: - - cd model-scripts/rdinfra - ./tftf.sh -p rdn1edge -a <additional_params> - - -Supported command line options are listed below - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to execute the TF-A Tests are as listed below. - - - :: - - ./tftf.sh -p rdn1edge - - - This command starts the execution of the TF-A Tests on the RD-N1-Edge - model and the results are displayed on the console. - - - :: - - ./tftf.sh -p rdn1edge -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the TF-A Tests on the RD-N1-Edge - model and the results are displayed on the console. Additional - parameters to the model are supplied using the -a command line - parameter. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/rdn1edge/how-to/ubuntu-test.rst b/docs/rdn1edge/how-to/ubuntu-test.rst deleted file mode 100644 index f588f09..0000000 --- a/docs/rdn1edge/how-to/ubuntu-test.rst +++ /dev/null @@ -1,223 +0,0 @@ -How to build RD-N1-Edge platform software to install and boot Ubuntu distro -=========================================================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Ubuntu distribution boot support --------------------------------- -RD-N1-Edge software stack supports the installation and boot of Ubuntu 18.04 -Bionic distribution. The Ubuntu distribution is installed on a SATA disk and the -installed image can be used for multiple boots. - - -Procedure to build RD-N1-Edge software stack for Ubuntu boot ------------------------------------------------------------- - -The RD-N1-Edge platform software stack has to be first built to prepare for the -Ubuntu distribution installation step. The procedure to execute the RD-N1-Edge -platform stack is listed below. - -To build the RD-N1-Edge software stack, the command to be used is - - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge <command> - - - Supported command line options are listed below - - - <command> - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -An example of the command to begin the installation of the Ubuntu distribution -is listed below. - - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge all - - - This command cleans, builds and packages the RD-N1-Edge software stack - needed for the Ubuntu installation/boot test for RD-N1-Edge platform. - - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge build - - - This command performs an incremental build of the software components - included in the software stack for the RD-N1-Edge platform. Note: this - command should be followed by the ``package`` command to complete the - preparation of the fip image. - - - :: - - ./build-scripts/build-test-uefi.sh -p rdn1edge package - - - This command packages the previously build software stack and prepares - the fip image. - - -Procedure for installing Ubuntu distro on RD-N1-Edge platform -------------------------------------------------------------- - -Ubuntu installer supports installation only through a CDROM disk. Hence, the -Ubuntu installation disk (ISO image) cannot be used with the RD-N1-Edge model. As -an alternate, Ubuntu can be installed through the PXE boot with the help of -the network installer which can be downloaded from `here <http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/current/images/netboot/netboot.tar.gz>`_. -Refer the `steps to setup PXE server`_ before beginning the installation. - -The following steps can be followed to begin the installation process. - -Create an empty disk image on which the Ubuntu installation will be done. - - :: - - cd model-scripts/rdinfra - dd if=/dev/zero of=<disk_image_name>.satadisk bs=1G count=<size in GB> - - - For example, use the following command to create a disk size of 4GB - - :: - - dd if=/dev/zero of=ubuntu_pxe.satadisk bs=1G count=4 - -The command to begin the installation is: - - :: - - ./distro.sh -p rdn1edge -d <disk_image_name> -n [true|false] -a <additional_params> - - -Supported command line options are listed below - - - -d <disk_image_path> - - - Path to the created disk image on which Ubuntu will be installed. - - - -n [true|false] - - - Controls the use of network ports by the model. Since this installation - has to be done through the network, this must be set to 'true'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -An example of the command to begin the boot of the Ubuntu distribution is -listed below. - - - :: - - ./distro.sh -p rdn1edge -d ./ubuntu_pxe.satadisk -n true - - - This command will start the RD-N1-Edge model and loads the edk2 - firmware. - - - After the console reaches loading of Tianocore edk2 firmware, press - escape to enter the UEFI menu and select the Boot Manager option. If - PXE setup is done correctly, you will see an option - ``UEFI PXEv4 (Mac:<random-mac-address>)``. Select the UEFI PXEv4 option - to continue the PXE boot. After few seconds, the model will acquire IP - address and find the tftp sever. - - - The RD-N1-Edge platform supports a total of 8GB of DDR memory out of - which 6GB of memory is located above the 32-bit memory space. The Ubuntu - installation fails if the upper 6GB is enabled. To disable the use of - the upper 6GB, at the grub menu displayed during the installation, - edit the kernel boot parameters as below limiting the DDR memory to - 2032MB (2GB - 16MB) for SATA disk detection. - - :: - - setparams 'Install' - set background_color=black - linux /ubuntu-installer/arm64/linux ---quiet ip=dhcp mem=2032m - initrd /ubuntu-installer/arm64/initrd.gz - - - - - From here on, follow the instructions of the Ubuntu installer. For more - information about the installation procedure, please refer this - `link <https://help.ubuntu.com/lts/installation-guide/arm64/ch06s03.html>`_. - - -Procedure for booting Ubuntu distro on RD-N1-Edge platform ----------------------------------------------------------- - -To boot the Ubuntu distro, use the following command: - - :: - - cd model-scripts/rdinfra - ./distro.sh -p rdn1edge -d <satadisk_path> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -d <satadisk_path> - - - Path to the installed SATA disk image created using the previous - section. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example command functionality are as listed below. - - - :: - - ./distro.sh -p rdn1edge - - - This command looks for the available .satadisk image in the - ``model-scripts/rdinfra`` folder and boots with that image. If multiple - .satadisk images are found, it will list them all but won't boot. - - - :: - - ./distro.sh -p rdn1edge -d ./ubuntu_pxe.satadisk - - - This command begins the distro boot from the ``ubuntu_pxe.satadisk`` - image. - - - During boot, at the grub menu, edit the kernel boot parameters as below for - enabling earlycon output and limiting the DDR memory to 2032MB for - SATA disk detection - - :: - - setparams 'Install' - set background_color=black - linux /ubuntu-installer/arm64/linux mem=2032m earlycon=pl011,0x7ff80000 console=ttyAMA0,115200 - initrd /ubuntu-installer/arm64/initrd.gz - - Save and exit the grub menu. This boot will then continue up to the login - prompt. - - -This completes the validation of the Ubuntu distribution installation and boot -functionalities. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - -.. _steps to setup PXE server: setup-pxe-server.rst diff --git a/docs/rdn1edge/user-guide.rst b/docs/rdn1edge/user-guide.rst index 8cb4ff3..b1c696a 100644 --- a/docs/rdn1edge/user-guide.rst +++ b/docs/rdn1edge/user-guide.rst @@ -1,287 +1,2 @@ -RD-N1-Edge and RD-N1-Edge-Dual platform user guide -================================================== - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Introduction ------------- - -RD (Reference Design) is a collection of resources to provide a representative -view of typical compute subsystems that can be designed and implemented using -specific generations of Arm IP. RD-N1-Edge in particular is based on: - - - 8x `Neoverse N1 Cores <https://developer.arm.com/products/processors/neoverse/neoverse-n1>`_ - with DynamIQ Shared Unit (DSU) - - Dedicated L2 cache: 512KB per core - - Shared L3 cache: 2MB per cluster - - CMN-600 with CML option: 8MB System Level Cache and 16MB Snoop Filter - - DMC-620 with 2xRDIMM DDR4-3200 - - Multiple AXI expansion ports for I/O Coherent PCIe, Ethernet, offload - - Arm Cortex-M7 for System Control Processor (SCP) and - Manageability Control Processor (MCP) - -RD-N1-Edge also supports a dual-chip configuration in which two RD-N1-Edge -platforms are connected through high speed CCIX link. The CCIX link is enabled -by CMN600's Coherent Multichip Link. Such platforms are called RD-N1-Edge-Dual -hereafter. - -This document is a user guide on how to setup, build and run the software stack -of RD-N1-Edge and RD-N1-Edge-Dual on Fixed Virtual Platform. - - -Host machine requirements -------------------------- - -The minimum recommended host PC specification for building the software stack -and running the RD-N1-Edge and RD-N1-Edge-Dual FVP model is a dual-core -processor running at 2GHz with 8GB of RAM. For best performance, use a machine -with a quad-core processor running at 2.6GHz with 16GB of RAM with free hard -disk space of at least 64GB. - -The software package has been tested on **Ubuntu 16.04 LTS (64-bit)** and -**Ubuntu 18.04 LTS (64-bit)**. This guide assumes that the user is on either of -this operating system. - - -Repo tool setup ---------------- - -The software stack for RD-N1-Edge and RD-N1-Edge-Dual is available in multiple -git repositories. In order to simplify downloading the software stack, `repo tool <https://source.android.com/setup/develop/repo>`_ -can be used. This section explains how to setup git and repo tool. - -- Install Git by using the following command - - :: - - sudo apt-get install git - -- Git installation can be confirmed by checking the version - - :: - - git --version - - This should return the git version in a format such as ``git version 2.7.4`` - -- Set name and email address in git - - :: - - git config --global user.name "<your-name>" - git config --global user.email "<your-email@example.com>" - -- Download the repo tool - - :: - - sudo apt-get install repo - -This completes the setup of the repo tool. - - -Syncing the software stack --------------------------- - -The manifest file, which contains the location of all the git repositories of -RD-N1-Edge and RD-N1-Edge-Dual software stack, is available `here <https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git/>`_. -This section explains how to sync the software stack. - -- Switch to a new folder - - :: - - mkdir rdn1edge - cd rdn1edge - -- For obtaining the latest *stable* software stack, use the following commands - to sync: - - - For RD-N1-Edge: - - :: - - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m pinned-rdn1edge.xml -b refs/tags/<RELEASE_TAG> - repo sync -j $(nproc) --fetch-submodules --force-sync - - - For RD-N1-Edge-Dual: - - :: - - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m pinned-rdn1edgex2.xml -b refs/tags/<RELEASE_TAG> - repo sync -j $(nproc) --fetch-submodules --force-sync - - Note: The RELEASE_TAG can be found in the release notes, if obtained. If - a release note is not available, or if a RELEASE_TAG is not known, see the - section "Release Tags" below to obtain the most recent release tag. - -- For obtaining the software stack with latest *upstream updates* but which - might not have been fully validated, use the following commands to sync: - - - For RD-N1-Edge: - - :: - - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m rdn1edge.xml -b master - repo sync -j $(nproc) --fetch-submodules --force-sync - - - For RD-N1-Edge-Dual: - - :: - - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m rdn1edgex2.xml -b master - repo sync -j $(nproc) --fetch-submodules --force-sync - -This will download the RD-N1-Edge or RD-N1-Edge-Dual software stack into the -``rdn1edge`` folder. - - -Installing prerequisites ------------------------- - -Run the following command to install all the required prerequisites to build the -software stack: - - :: - - sudo ./build-scripts/rdinfra/install_prerequisites.sh - -It is mandatory to execute this script at least once before build and executing -the software stack. - - -Downloading the GCC toolchain binaries --------------------------------------- - -In addition to the prerequisites installed, gcc toolchain binaries have to be -downloaded and placed at the ``tools/gcc`` folder. Use the following commands -to download and untar the binaries: - - :: - - # Move to the rdn1edge software stack directory - cd rdn1edge - - # Create a folder for gcc under tools folder - mkdir -p tools/gcc - cd tools/gcc - - # Download and extract the binaries - wget https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/aarch64-linux-gnu/gcc-linaro-6.2.1-2016.11-x86_64_aarch64-linux-gnu.tar.xz - tar -xJf gcc-linaro-6.2.1-2016.11-x86_64_aarch64-linux-gnu.tar.xz - wget https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/arm-linux-gnueabihf/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf.tar.xz - tar -xJf gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf.tar.xz - wget https://armkeil.blob.core.windows.net/developer//sitecore/shell/-/media/Files/downloads/gnu-rm/5_4-2016q3/gcc-arm-none-eabi-5_4-2016q3-20160926-linux,-d-,tar.bz2 - tar -xjf gcc-arm-none-eabi-5_4-2016q3-20160926-linux,-d-,tar.bz2 - -This completes the setup of the GCC toolchain binaries. - - -Obtaining the RD-N1-Edge and RD-N1-Edge-Dual Fast Model -------------------------------------------------------- - -RD-N1-Edge Fast Model version 11.8 can be downloaded from `arm developer page <https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms>`_ -(under section *Arm Neoverse FVPs*). - -User can request for the latest version of RD-N1-Edge and RD-N1-Edge-Dual Fast -Models through `this page <https://developer.arm.com/products/system-design/fixed-virtual-platforms>`_ -or contact arm directly at this email address: `support-connect@arm.com <mailto:support-connect@arm.com>`_. - -Follow the instruction in the installer and setup the FVP. Typically, the -installer will ask to create a new folder in the home directory. You can either -install the FVP in the home folder, or in the ``fastmodel/refinfra`` folder -inside the ``rdn1edge`` folder. If you would like to install in the -``fastmodel/refinfra`` folder, when asked for the install location, -enter as ``fastmodel/refinfra``. - -Before launching any scripts from ``model-scripts`` folder, export the absolute -path of the model as an environment variable. - - :: - - export MODEL=<absolute-path-of-the-model-executable> - -This completes the steps to obtain the RD-N1-Edge and RD-N1-Edge-Dual Fast -Models. - - -Supported Features ------------------- - -RD-N1-Edge and RD-N1-Edge-Dual software stack supports number of tests to -explore its features. To begin with, one can start with the busybox boot, and -then try installing and booting various linux distribution. RD-N1-Edge is target -for infrastructure platforms and it supports variety of infrastructure specific -features. - -All the supported tests for RD-N1-Edge and RD-N1-Edge-Dual are listed below: - -+----------------------------------------------+-------------+-----------------+ -| Filesystems | RD-N1-Edge | RD-N1-Edge-Dual | -+==============================================+=============+=================+ -| `Busybox`_ | Supported | Supported | -+----------------------------------------------+-------------+-----------------+ -| `Fedora 27 Enterprise Linux Distribution`_ | Supported | | -+----------------------------------------------+-------------+-----------------+ -| `Debian 9.8.0 Enterprise Linux Distribution`_| Supported | | -+----------------------------------------------+-------------+-----------------+ -| `Ubuntu 18.4 Enterprise Linux Distribution`_ | Supported | | -+----------------------------------------------+-------------+-----------------+ - -+----------------------------------------------+-------------+-----------------+ -| Tests | RD-N1-Edge | RD-N1-Edge-Dual | -+==============================================+=============+=================+ -| `ACS`_ | Supported | | -+----------------------------------------------+-------------+-----------------+ -| `KVM`_ | Supported | | -+----------------------------------------------+-------------+-----------------+ -| `RAS`_ | | | -+----------------------------------------------+-------------+-----------------+ -| `Secure Boot`_ | | | -+----------------------------------------------+-------------+-----------------+ -| `TFTF`_ | Supported | | -+----------------------------------------------+-------------+-----------------+ - -Release Tags ------------- - -Most recent release tag: - - RD-N1-Edge platform: RD-INFRA-2020.09.30 - - RD-N1-Edge-Dual platform: RD-INFRA-2020.09.30 - -Here's the list of release tags and corresponding Fast Model version supported: - -+-----------------------+-------------------------+-----------------------------+ -| Release Tag | RD-N1-Edge FVP Version | RD-N1-Edge-Dual FVP Version | -+=======================+=========================+=============================+ -| RD-INFRA-2020.09.30 | 11.12.43 | 11.12.43 | -+-----------------------+-------------------------+-----------------------------+ -| | | | -+-----------------------+-------------------------+-----------------------------+ -| | | | -+-----------------------+-------------------------+-----------------------------+ -| | | | -+-----------------------+-------------------------+-----------------------------+ -| | | | -+-----------------------+-------------------------+-----------------------------+ - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - - -.. _Busybox: how-to/busybox-boot.rst -.. _Fedora 27 Enterprise Linux Distribution: how-to/fedora-test.rst -.. _Debian 9.8.0 Enterprise Linux Distribution: how-to/debian-test.rst -.. _Ubuntu 18.4 Enterprise Linux Distribution: how-to/ubuntu-test.rst -.. _ACS: how-to/acs-test.rst -.. _KVM: how-to/kvm-test.rst -.. _RAS: how-to/ras-test.rst -.. _Secure Boot: how-to/secureboot-test.rst -.. _TFTF: how-to/tftf-test.rst - +RD-N1-Edge platform documentation has been migrated to +https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/tree/master/docs/infra diff --git a/docs/sgi575/how-to/acs-test.rst b/docs/sgi575/how-to/acs-test.rst deleted file mode 100644 index cbb1f3e..0000000 --- a/docs/sgi575/how-to/acs-test.rst +++ /dev/null @@ -1,200 +0,0 @@ -How to build SGI-575 platform software and execute Arm ACS test suite -===================================================================== - - -.. section-numbering:: - :suffix: . - -.. contents:: - -What is Arm ACS ---------------- - -Architecture Compliance Suite (ACS) is used to ensure architectural compliance -across different implementations of the architecture. Arm Enterprise ACS -includes a set of examples of the invariant behaviours that are provided by a -set of specifications for enterprise systems (e.g. SBSA, SBBR, etc.), so that -implementers can verify if these behaviours have been interpreted correctly. -ACS is delivered with tests in source form along with a build script, the output -of the build being a bootable Linux UEFI Validation (LUV) OS image that can run -all tests required by these specifications. - -What does ACS test on SGI-575 demonstrate ------------------------------------------ - -SGI-575 platform is targetted for enterprise and network infrastructure -use cases. This requires the SGI-575 platform to be compliant to the various -architectural specifications such as SBSA and SBBR. The ACS test on SGI-575 -platform helps with building the platform firmware stack and ACS test suite -and then validating the same on the SGI-575 platform. The test results are -stored on the luv-live disk image which can be retrived from this disk. The -results can then be looked into to determine the conformance to the SBSA and -SBBR standards. - -Procedure to build ACS test for SGI-575 platform ------------------------------------------------- - -The procedure to build the ACS test suite along the SGI-575 platform software -stack is listed below. The components of the SGI-575 platform software stack -that are built is limited to those that provide the EFI implementation and the -EFI shell on the SGI-575 platforms (i.e, SCP, TF-A and EDK2). - -To build the SGI-575 software stack, ACS tests and to prepares the disk image, -the command to be used is - - :: - - ./build-scripts/build-test-acs.sh -p sgi575 <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/build-test-acs.sh -p sgi575 all - - - This command cleans, builds and packages the SGI-575 software stack - required for the ACS test on SGI-575 platform. The ACS test suite is - also built from source. - - - :: - - ./build-scripts/build-test-acs.sh -p sgi575 build - - - This command performs an incremental build of the software components - included in the software stack for ACS test on the SGI-575 platform. - Note: this command should be followed by the 'package' command to - complete the preparation of the fip and the luv-live disk image. - - - :: - - ./build-scripts/build-test-acs.sh -p sgi575 package - - - This command packages the previously build software stack and prepares - the fip and the luv-live disk image. - -The above build command includes steps to build the ACS test suite from the -source. In case it is desired to use a pre-built image of the ACS test -luv-live disk image, the build can be restricted to the platform software -firmware components such as SCP, TF-A and EDK2. The command to be used to -build the firmware components but not ACS test suite from the source is - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 all - - - This command cleans, builds and packages the SGI-575 software stack - required for the ACS test on SGI-575 platform. - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 build - - - This command performs an incremental build of the software components - included in the software stack for ACS test on the SGI-575 platform. - Note: this command should be followed by the 'package' command to - complete the preparation of the fip image. - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 package - - - This command packages the previously build software stack and prepares - the fip image. - - -Procedure for executing ACS test for SGI-575 platform ------------------------------------------------------ - -The procedure to execute the ACS test cases on the SGI-575 platform is listed -below. - - :: - - cd model-scripts/sgi - ./acs.sh -p sgi575 -v <path to luv-live image> -n [true|false] -a <additional_params> - - -Supported command line options are listed below - - - -v <absolute path to the luv-live prebuilt image> (optional) - - - Allows use of a pre-built luv-live image for the test. The absolute - path to the luv-live image has be supplied as the parameter. This - parameter is optional, and if not specified, the luv-live image is - picked up from the location into which the images are packaged by the - build command. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> (optional) - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to execute the ACS tests are as listed below. - - - :: - - ./acs.sh -p sgi575 - - - This command starts the execution of the SGI-575 model and the ACS tests - are executed. The luv-live image is picked up from the location - ./output/sgi575/luv-live-image-gpt.img. - - - :: - - ./acs.sh -p sgi575 -v /tmp/luv-live-image-gpt.img - - - This command starts the execution of the SGI-575 model and the ACS tests - are executed. The luv-live image is picked up from the location - ./tmp/luv-live-image-gpt.img. - - - :: - - ./acs.sh -p sgi575 -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the SGI-575 model with networking - enable and the ACS tests are executed. The luv-live image is picked up - from the location ./output/sgi575/luv-live-image-gpt.img. Additional - parameters to the model are supplied using the -a command line - parameter. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/sgi575/how-to/busybox-boot.rst b/docs/sgi575/how-to/busybox-boot.rst deleted file mode 100644 index 2d979cd..0000000 --- a/docs/sgi575/how-to/busybox-boot.rst +++ /dev/null @@ -1,137 +0,0 @@ -How to build SGI-575 platform software to validate busybox boot -=============================================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - -Busybox boot on SGI-575 platform --------------------------------- - -Busybox is a lightweight executable which packages lots of POSIX compliant UNIX -utilities in a single file system. The busybox boot test on SGI-575 platform -ensures that the SGI-575 software stack which runs on the model is able to boot -a Linux operating system with a busybox filesystem. - -Boot test is especially helpful when porting the software stack for new -platforms which are derivative of the SGI-575 platform as this test can be -quickly executed to ensure that the various software components are properly -integrated and verify the basic functionality of various software components. -As part of this test, the following components of the software stack are built - -*TF-A*, *UEFI*, *Linux*, *GRUB*, *SCP*. - -This document describes how to build and execute the Boot test on the *SGI-575* -fastmodel. - -Procedure to build Busybox boot test for SGI-575 platform ---------------------------------------------------------- - -This section describes how to build the disk image for busybox boot test. The -disk image consists of an EFI partition which has grub and an ext3 partition -which has the linux kernel image. Examples on how to use the build command for -busybox boot test are listed below. - -To build the SGI software stack, the command to be used is - - :: - - ./build-scripts/sgi/build-test-busybox.sh -p sgi575 <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/sgi/build-test-busybox.sh -p sgi575 all - - - This command cleans, builds and packages the SGI software stack needed - for the busybox boot test on SGI-575 platform. - - - :: - - ./build-scripts/sgi/build-test-busybox.sh -p sgi575 build - - - This command performs an incremental build of the software components - included in the software stack for the SGI-575 platform. Note: this - command should be followed by the 'package' command to complete the - preparation of the FIP and the disk image. - - - :: - - ./build-scripts/sgi/build-test-busybox.sh -p sgi575 package - - - This command packages the previously built software stack and prepares - the FIP and the disk image. - -Procedure for validating Busybox boot test for SGI-575 platform ---------------------------------------------------------------- - -After the build for busybox boot test is complete, the following command starts -the execution of the *SGI-575* fastmodel and the software boots up to the -Busybox prompt. Examples on how to use the command are listed below. - -To boot up to the Busybox prompt, the command to be used is - - :: - - cd model-scripts/sgi - ./boot.sh -p sgi575 -a <additional_params> -n [true|false] - - -Supported command line options are listed below - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the Boot test are as listed below. - - - :: - - ./boot.sh -p sgi575 - - - This command starts the execution of the SGI-575 model and the software - boots up to the Busybox prompt. - - - :: - - ./boot.sh -p sgi575 -n true - - - This command starts the execution of the SGI-575 model and the - software boots up to the Busybox prompt. The model supports - networking allowing the software running within the model to access - the network. - - - :: - - ./boot.sh -p sgi575 -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the SGI-575 model with networking - enabled and the software boots up to the Busybox prompt. Additional - parameters to the model are supplied using the -a command line - parameter. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/sgi575/how-to/create-tap-interface.rst b/docs/sgi575/how-to/create-tap-interface.rst deleted file mode 100644 index 97b1df9..0000000 --- a/docs/sgi575/how-to/create-tap-interface.rst +++ /dev/null @@ -1,59 +0,0 @@ -How to create tap interface to enable networking for FVPs -========================================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Context -------- - -SGI-575 fast model supports virtual networking and it can interface with the -host PC network through the tap interface setup on the host machine. The steps -to setup a TAP interface on this host PC are listed below. This requires Ubuntu -16.04 or Ubuntu 18.04 as the host PC. - - -How to setup tap interface --------------------------- - -- Install the ``bridge-utils`` package - - :: - - sudo apt-get install bridge-utils - -- The first step is to create a bridge and add the host PC network as its - interface. Here, ``br0`` is the bridge name and ``enp0s3`` is the host pc - network device name. Replace these names with the names of the interfaces - used on the host PC. - - :: - - sudo brctl addbr br0 - sudo brctl addif br0 enp0s3 - sudo ifconfig enp0s3 0.0.0.0 - sudo ifconfig br0 up - sudo dhclient br0 - -- Next setup is to add the tap interface. Here, ``tap0`` is the name of the tap - interface. - - :: - - sudo ip tuntap add dev tap0 mode tap user $(whoami) - sudo ifconfig tap0 0.0.0.0 promisc up - sudo brctl addif br0 tap0 - -Note: These steps do not make a persistent instance of the bridge and the tap -interface. After the host PC reboots, these steps has to be repeated again. - -Refer `this documentation <https://wiki.linuxfoundation.org/networking/bridge>`_ -for more details. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.*
\ No newline at end of file diff --git a/docs/sgi575/how-to/debian-test.rst b/docs/sgi575/how-to/debian-test.rst deleted file mode 100644 index dfcb89d..0000000 --- a/docs/sgi575/how-to/debian-test.rst +++ /dev/null @@ -1,223 +0,0 @@ -How to build SGI-575 platform software to install and boot Debian distribution -============================================================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Debian distribution boot support --------------------------------- -SGI-575 software stack supports the installation and boot of Debian 9.8 Stretch -Distribution (Debian 9.8 Distribution). The Debian distribution is installed on -a SATA disk and the installed image can be used for multiple boots. - - -Procedure to build SGI-575 software stack for debian boot ---------------------------------------------------------- - -The SGI-575 platform software stack has to be first built to prepare for the -debian distribution installation step. The procedure to execute the SGI-575 -platform stack is listed below. - -To build the SGI-575 software stack, the command to be used is - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 <command> - - - Supported command line options are listed below - - - <command> - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -An example of the command to begin the installation of the debian distribution -is listed below. - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 all - - - This command cleans, builds and packages the SGI-575 software stack - needed for the Debian installation/boot test for SGI-575 platform. - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 build - - - This command performs an incremental build of the software components - included in the software stack for the SGI-575 platform. Note: this - command should be followed by the ``package`` command to complete the - preparation of the fip image. - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 package - - - This command packages the previously build software stack and prepares - the fip image. - - -Procedure for installing Debian distro on SGI-575 platform ----------------------------------------------------------- - -After the build for the distro is complete, Debian can be installed into a -SATA disk image. Before beginning the installation process download the iso -image of the required debian version. For example, Debian 9.8 Strech CD ISO -image can be downloaded from `here <https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/>`_ -or with this `direct link <https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/debian-9.8.0-arm64-xfce-CD-1.iso>`_. - -The command used to begin the distro installation is: - - :: - - cd model-scripts/sgi - ./distro.sh -p sgi575 -i <iso_image_path> -s <disk size> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -i <iso_image_path> - - - Path to the downloaded installer iso image. - - - -s <disk_size> - - - Size of the SATA disk image (in GB) to be created. 4GB and above is - good enough for most use cases. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -An example of the command to begin the boot of the debian distribution is -listed below. - - - :: - - ./distro.sh -p sgi575 -i ./debian-9.8.0-arm64-xfce-CD-1.iso -s 4 - - - This command creates a 4GB SATA disk image, boot the SGI-575 software - stack and start the installation of debian distro. - - - The SGI-575 platform supports a total of 8GB of DDR memory out of which - 6GB of memory is located above the 32-bit memory space. The debian - installation fails if the upper 6GB is enabled. To disable the use of - the upper 6GB, at the grub menu displayed during the installation, - edit the kernel boot parameters as below for enabling earlycon output - and limiting the DDR memory to 2032MB (2GB - 16MB) for SATA disk - detection. - - :: - - setparams 'Install' - set background_color=black - linux /install.a64/vmlinuz mem=2032M earlycon=pl011,0x7ff80000 console=ttyAMA0,115200 - initrd /intsall.a64/initrd.gz - - - From here on, follow the instructions of the Debian installer. For more - information about the installation procedure, please refer this - `link <https://www.debian.org/releases/stable/arm64/index.html.en>`_. - - - During installation, the installer will prompt the user with the message - 'Load CD-ROM drivers from removable media' and display two options - - Yes/No. - - - Select the option 'No' which would again display two options - - Yes/No. - - Select the option 'Yes' which will display 'Automatic detection - did not find CD-ROM'. - - Module needed for accessing CD-ROM and display two options - - - none - - cdrom - - - Select the option 'none' and enter ``/dev/vda``. The installation - media on the virtio disk will be detected and installation - continues. - - - After the installation is completed, the disk image with a random name - "<number>.satadisk" will be created in model-scripts/sgi/ folder. User - should use this disk image when booting the Debian distribution. - - -Procedure for booting Debian distro on SGI-575 platform -------------------------------------------------------- - -To boot the debian distro, use the following command: - - :: - - cd model-scripts/sgi - ./distro.sh -p sgi575 -d <satadisk_path> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -d <satadisk_path> - - - Path to the installed SATA disk image created using the previous - section. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example command functionality are as listed below. - - - :: - - ./distro.sh -p sgi575 - - - This command looks for the available .satadisk image in the - ``model-scripts/sgi`` folder and boots with that image. If multiple - .satadisk images are found, it will list them all but won't boot. - - - :: - - ./distro.sh -p sgi575 -d ./debian.satadisk - - - This command begins the distro boot from the ``debian.satadisk`` image. - - - During boot, at the grub menu, edit the kernel boot parameters as below for - enabling earlycon output and limiting the DDR memory to 2032MB for - SATA disk detection - - :: - - setparams 'Install' - set background_color=black - linux /install.a64/vmlinuz mem=2032M earlycon=pl011,0x7ff80000 console=ttyAMA0,115200 - initrd /intsall.a64/initrd.gz - - Save and exit the grub menu. This boot will then continue up to the login - prompt. - - -This completes the validation of the Debian distribution installation and boot -functionalities. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/sgi575/how-to/fedora-test.rst b/docs/sgi575/how-to/fedora-test.rst deleted file mode 100644 index cce1890..0000000 --- a/docs/sgi575/how-to/fedora-test.rst +++ /dev/null @@ -1,177 +0,0 @@ -How to build SGI-575 platform software to install and boot Fedora distribution -============================================================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Fedora distribution boot support --------------------------------- -SGI-575 software stack supports the installation and boot of Fedora Enterprise -Server Distribution (Fedora 27 Distribution). The Fedora distribution is -installed on a SATA disk and the installed image can be used for multiple boots. - - -Procedure to build SGI-575 software stack for Fedora boot ---------------------------------------------------------- - -The SGI-575 platform software stack has to be first built to prepare for the -Fedora distribution installation step. The procedure to execute the SGI-575 -platform stack is listed below. - -To build the SGI-575 software stack, the command to be used is - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 <command> - - - Supported command line options are listed below - - - <command> - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -An example of the command to begin the installation of the Fedora distribution -is listed below. - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 all - - - This command cleans, builds and packages the SGI-575 software stack - needed for the Fedora installation/boot test for SGI-575 platform. - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 build - - - This command performs an incremental build of the software components - included in the software stack for the SGI-575 platform. Note: this - command should be followed by the ``package`` command to complete the - preparation of the fip image. - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 package - - - This command packages the previously build software stack and prepares - the fip image. - - -Procedure for installing Fedora distro on SGI-575 platform ----------------------------------------------------------- - -After the build for the distro is complete, Fedora can be installed into a -SATA disk image. Before beginning the installation process download the iso -image of the required Fedora version. For example, the Fedora distribution iso image -has to be downloaded from `here <https://dl.fedoraproject.org/pub/fedora-secondary/releases/27/Server/aarch64/iso/>`_ -or with this `direct link <https://dl.fedoraproject.org/pub/fedora-secondary/releases/27/Server/aarch64/iso/Fedora-Server-dvd-aarch64-27-1.6.iso>`_. - -The command used to begin the distro installation is: - - :: - - cd model-scripts/sgi - ./distro.sh -p sgi575 -i <iso_image_path> -s <disk size> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -i <iso_image_path> - - - Path to the downloaded installer iso image. - - - -s <disk_size> - - - Size of the SATA disk image (in GB) to be created. 4GB and above is - good enough for most use cases. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -An example of the command to begin the boot of the Fedora distribution is -listed below. - - - :: - - ./distro.sh -p sgi575 -i ./Fedora-Server-dvd-aarch64-27-1.6.iso -s 4 - - - This command creates a 4GB SATA disk image, boot the SGI-575 software - stack and start the installation of Fedora distro. - - - From here on, follow the instructions of the Fedora installer. For more - information about the installation procedure, please refer this - `link <https://docs.fedoraproject.org/en-US/index.html>`_. - - - After the installation is completed, the disk image with a random name - "<number>.satadisk" will be created in model-scripts/sgi/ folder. User - should use this disk image when booting the Fedora distribution. - - -Procedure for booting Fedora distro on SGI-575 platform -------------------------------------------------------- - -To boot the Fedora distro, use the following command: - - :: - - cd model-scripts/sgi - ./distro.sh -p sgi575 -d <satadisk_path> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -d <satadisk_path> - - - Path to the installed SATA disk image created using the previous - section. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example command functionality are as listed below. - - - :: - - ./distro.sh -p sgi575 - - - This command looks for the available .satadisk image in the - ``model-scripts/sgi`` folder and boots with that image. If multiple - .satadisk images are found, it will list them all but won't boot. - - - :: - - ./distro.sh -p sgi575 -d ./fedora.satadisk - - - This command begins the distro boot from the ``fedora.satadisk`` image. - -This completes the validation of the Fedora distribution installation and boot -functionalities. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/sgi575/how-to/kvm-test.rst b/docs/sgi575/how-to/kvm-test.rst deleted file mode 100644 index 76ec6d3..0000000 --- a/docs/sgi575/how-to/kvm-test.rst +++ /dev/null @@ -1,188 +0,0 @@ -How to build SGI-575 platform software to validate KVM feature -============================================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - -What is KVM ------------ - -Kernel Virtual Machine (KVM) is an virtualization module built in the linux -kernel which lets the user to turn linux into a hypervisor to allow hosting -single/multiple isolated guests or virtual machine. KVM requires a processor -with hardware virtualization extensions. - -Currently, KVM is part of linux kernel. Some of the features of KVM are: - -- Over-committing : KVM allows to allocate more virtulized CPU or memory - for the virtual machine than that of the host. -- Thin provisioning : KVM allows to allocate and optimize the flexible - storage for the virtual machines. -- Disk throttling : KVM allows to set limits fror disk I/O requests. -- Virtual CPU hot plug: KVM allows ability to increase the CPU count of the - virtual machine durting run time. - - -What does KVM test on SGI-575 demonstrate ------------------------------------------ - -The SGI-575 platform demonstrates boot up 2+ instances of guest OS's using -`lvkm tool <https://github.com/lkvm/lkvm>`_. Linux KVM tool supports booting -guest OS's of the same architecture. For SGI-575 booting only ARM based virtual -machine is supported. KVM test for SGI-575 demonstrates booting -Linux Kernel v4.18 or Linux Kernel v4.13 as guest with Linux Kernel v4.18 as -the host. - - -Procedure to build KVM test for SGI platforms ---------------------------------------------- - -Execution of the KVM test requires booting a Fedora distribution system with the -kernel built for the SGI-575 platform. The first step would be to -get a `installed Fedora distribution`_ satadisk image and `prepare the image`_. -After the Fedora satadisk image has been prepared, the ``fedora.satadisk`` image -file has to be placed in the ``prebuilts/refinfra`` directory. Now, build the -firmware components and the kernel image needed for running the KVM test. For -generation of these image, the build command to be used is listed below. - -To build the SGI software stack, the following command can be used - - :: - - ./build-scripts/sgi/build-test-kvm.sh -p sgi575 <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/sgi/build-test-kvm.sh -p sgi575 all - - - This command cleans, builds and packages the SGI software stack needed - for the KVM test for SGI-575 platform. - - - :: - - ./build-scripts/sgi/build-test-kvm.sh -p sgi575 build - - - This command performs an incremental build of the software components - included in the software stack for the SGI-575 platform. Note: this - command should be followed by the 'package' command to complete the - preparation of the fip and the disk image. - - - :: - - ./build-scripts/sgi/build-test-kvm.sh -p sgi575 package - - - This command packages the previously build software stack and prepares - the fip and the loads the kernel into the disk image. - - -Procedure for validating KVM test for SGI-575 platform ------------------------------------------------------- - -After the build for the KVM test is complete, to boot upto the Fedora login -prompt using the SGI software stack, the command to be used is - - :: - - cd model-scripts/sgi - ./kvm.sh -p sgi575 -a <additional_params> -n [true|false] - -Note: ``fedora.satadisk`` is expected at the location ``prebuilts/refinfra`` for -this command to work. - -Supported command line options are listed below - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the KVM functionality are as listed below. - - - :: - - ./kvm.sh -p sgi575 - - - This command starts the execution of the SGI-575 model and the software - boots upto the Fedora login prompt. - - - :: - - ./kvm.sh -p sgi575 -n true - - - This command starts the execution of the SGI-575 model and the - software boots upto the Fedora login prompt. The model supports - networking allowing the software running within the model to access - the network. - - - :: - - ./kvm.sh -p sgi575 -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the SGI-575 model with networking - enabled and the software boots upto the Fedora login prompt. Additional - parameters to the model are supplied using the -a command line - parameter. - - -During the system boot, select the 'Fedora (refinfra) 27 (Server Edition)' -kernel on the grub menu. After the boot is complete, login as the root user. - - - IMPORTANT: In the ``/root/`` directory, the lkvm executable is made - available as part of the `prepare fedora disk process`_. Before using - the lkvm tool, two dependencies (``glibc-static`` and ``libfdt-devel``) - need to be installed using the ``yum`` tool. This requires - `tap interface setup on the host`_ and the network parameter (``-n``) set - to be true while starting the test. Enabling the network interface allows - to model to connect to the internet through the network bridge interface - of the host PC. The command to install the dependencies for ``lkvm`` is: - - - :: - - yum install -y glibc-static libfdt-devel - - - After the dependencies are installed, kvm test can be done using the - following command: - - - :: - - ./lkvm run -k <path-to-linux-image> -c 8 --irqchip gicv3 -p "console=ttyS0,115200 earlycon=uart,mmio,0x3f8 debug" - - - For example to run the sgi kernel on the kvm, following command can be used: - - :: - - ./lkvm run -k /boot/vmlinux-refinfra -c 8 --irqchip gicv3 -p "console=ttyS0,115200 earlycon=uart,mmio,0x3f8 debug" - -This completes the validation of the KVM functionality. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - -.. _installed Fedora distribution: fedora-test.rst -.. _prepare the image: prepare-fedora-disk.rst -.. _prepare fedora disk process: prepare-fedora-disk.rst -.. _tap interface setup on the host: create-tap-interface.rst diff --git a/docs/sgi575/how-to/prepare-fedora-disk.rst b/docs/sgi575/how-to/prepare-fedora-disk.rst deleted file mode 100644 index 875a40b..0000000 --- a/docs/sgi575/how-to/prepare-fedora-disk.rst +++ /dev/null @@ -1,50 +0,0 @@ -How to prepare a fedora disk image for RAS and KVM test -======================================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Why to prepare the fedora disk image? -------------------------------------- - -Some of the feature validation on the SGI-575 platform requires a fedora -enterprise linux as the root filesystem. In this release, RAS and KVM feature -validation are the ones that require fedora enterprise linux as the root file -system. - -To simplify the validation of RAS and KVM features, it is recommended that the -disk with a installed version of the fedora enterprise linux is created. This -disk will be used as the root filesystem for the validation of RAS and KVM -features. - - -Preparing the fedora disk image -------------------------------- - -- Install a Fedora 27 Enterprise Linux distribution disk image. Refer to the - `procedure for installing Fedora`_ for detailed instructions on this. - -- Create the directory ``prebuilts/refinfra`` (if that does not exist) at the - root of the workspace. - -- Copy the installed fedora disk image at ``prebuilts/refinfra/fedora.satadisk`` - -- Use the following command to update the grub menu, download/unpack/load the - lvkm executable to the /root/ directory of the fedora disk. - Note: sudo permission is required for completing this step. - - :: - - sudo ./build-scripts/sgi/prepare-fedora-disk.sh - -This completes the procedure to prepare the fedora disk image. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - -.. _procedure for installing Fedora: fedora-test.rst diff --git a/docs/sgi575/how-to/ras-test.rst b/docs/sgi575/how-to/ras-test.rst deleted file mode 100644 index c0822c4..0000000 --- a/docs/sgi575/how-to/ras-test.rst +++ /dev/null @@ -1,193 +0,0 @@ -How to build SGI-575 platform software to validate platform RAS error handling -============================================================================== - - -.. section-numbering:: - :suffix: . - -.. contents:: - -What is RAS ------------ - -Reliability Availability and Serviceability are three aspects that are -considered to be vital to ensure correct functioning of a server system. These -require extensive support in the platform hardware and software to ensure that -the system is producing correct results and that in a scenario where the system -encounters a malfunctioning component, the system is able to: - - - identify and correct the error condition - - record and flag errors to an external component like a Board Management - Controller (BMC) - - provide for mechanisms to avoid or keep to a minimum, the system downtime - by supporting features like hot-swapping of failing components, or by - providing for redundancy in the system hardware. - -What does RAS test on SGI-575 demonstrate ------------------------------------------ - -The SGI-575 platform supports multiple RAS error sources. Out of these, the -RAS error handling test validates the DMC-620 single-bit RAS error injection and -error handling of features in the platform software. The RAS error injection and -error handling requires multiple software components (kernel and firmware -components) to work in tandem in order for the RAS errors to be detected and -propogated to the kernel. This RAS test demonstrates the error injection and -error handling of the DMC-620 single-bit RAS error. - -Procedure to build RAS test for SGI-575 platform ------------------------------------------------- - -The SGI-575 platform demonstrates the RAS feature by injecting a memory error -using RAS simulation capabilities in the DMC-620 controller. The RAS support -consists of the following components: - -- The DMC RAS driver. The driver executes as part of the S-EL0 Management Mode - and provides DMC RAS error handling and reporting. -- The TF-A SPM and SDEI modules which are responsible for handling system - interrupts and sending notifications to the DMC RAS driver and the Linux - kernel. -- APEI driver used to retrieve the system RAS errors from S-EL0 Management mode - code. This information is then used to populate the HEST ACPI table, for - future consumption by the Linux kernel. -- CPER Library which is used by individual RAS error handling drivers to - populate the CPER record with relevant data, to be passed on to the Linux - kernel on the non-secure side. -- The Linux kernel SDEI client which is part of the kernel ACPI APEI - notification mechanism. - -Execution of the RAS test requires booting a Fedora distribution system with the -kernel containing changes needed for the RAS test. The first step would be to -get a installed Fedora distribution satadisk image. After the Fedora SATA disk -image has been prepared, the Fedora.satadisk image file is created under the -prebuilts/refinfra directory. Now, build the firmware components and the kernel -image needed for running the RAS test. For generation of these image, the build -command to be used is listed below. - -To build the SGI-575 software stack, the command to be used is - - :: - - ./build-scripts/sgi/build-test-ras.sh -p sgi575 <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/sgi/build-test-ras.sh -p sgi575 all - - - This command cleans, builds and packages the SGI-575 software stack - needed for the RAS test for SGI-575 platform. - - - :: - - ./build-scripts/sgi/build-test-ras.sh -p sgi575 build - - - This command performs an incremental build of the software components - included in the software stack for the SGI-575 platform. Note: this - command should be followed by the 'package' command to complete the - preparation of the fip and the disk image. - - - :: - - ./build-scripts/sgi/build-test-ras.sh -p sgi575 package - - - This command packages the previously build software stack and prepares - the fip and the disk image. - -Procedure for validating RAS test for SGI-575 platform ------------------------------------------------------- - -After the build for the RAS test is complete, to boot upto the Fedora login -prompt using the SGI-575 software stack, the command to be used is - - :: - - cd model-scripts/sgi - ./ras.sh -p sgi575 -n [true|false] -a <additional_params> - - -Supported command line options are listed below - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> (optional) - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the RAS functionality are as listed below. - - - :: - - ./ras.sh -p sgi575 - - - This command starts the execution of the SGI-575 model and the software - boots upto the Fedora login prompt. - - - :: - - ./ras.sh -p sgi575 -n true - - - This command starts the execution of the SGI-575 model and the software - boots upto the Fedora login prompt. The model supports networking - allowing the software running within the model to access the network. - - - :: - - ./ras.sh -p sgi575 -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the SGI-575 model with networking - enabled and the software boots upto the Fedora login prompt. Additional - parameters to the model are supplied using the -a command line - parameter. - - -During the system boot, select the 'Fedora (refinfra) 27 (Server Edition)' -kernel on the grub menu. On a successful login into Fedora, execute the -following command on the Fedora shell prompt to inject the DMC-620 single-bit -RAS error. - - :: - - 'echo 0x123 > /sys/kernel/debug/sdei_ras_poison' - -On execution of this command, the error record dump, known as CPER dump would be -seen on the Fedora terminal's console, similar to the sample dump shown below. - - :: - - [115792.848999] ghes_edac: Internal error: Can't find EDAC structure - [115792.849003] [Firmware Warn]: GHES: Invalid address in generic error data: 0x1f03fedcd - [115792.849008] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 - [115792.849013] {1}[Hardware Error]: event severity: recoverable - [115792.849017] {1}[Hardware Error]: Error 0, type: corrected - [115792.849021] {1}[Hardware Error]: fru_id: 00000000-0000-0000-0000-000000000000 - [115792.849025] {1}[Hardware Error]: fru_text: - [115792.849029] {1}[Hardware Error]: section_type: memory error - [115792.849033] {1}[Hardware Error]: physical_address: 0x00000001f03fedcd - [115792.849038] {1}[Hardware Error]: physical_address_mask: 0xfffffffffffff000 - [115792.849042] {1}[Hardware Error]: error_type: 8, parity error - -This completes the validation of the RAS functionality. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/sgi575/how-to/redhat-test.rst b/docs/sgi575/how-to/redhat-test.rst deleted file mode 100644 index 791ef88..0000000 --- a/docs/sgi575/how-to/redhat-test.rst +++ /dev/null @@ -1,175 +0,0 @@ -How to build SGI-575 platform software to install and boot Red Hat distribution
-===============================================================================
-
-.. section-numbering::
- :suffix: .
-
-.. contents::
-
-
-Red Hat distribution boot support
----------------------------------
-SGI-575 software stack supports the installation and boot of Red Hat Enterprise
-Server Distribution (RHEL 7.4 Distribution). The Red Hat distribution is
-installed on a SATA disk and the installed image can be used for multiple boots.
-
-
-Procedure to build SGI-575 software stack for Red Hat boot
-----------------------------------------------------------
-
-The SGI-575 platform software stack has to be first built to prepare for the
-Red Hat distribution installation step. The procedure to execute the SGI-575
-platform stack is listed below.
-
-To build the SGI-575 software stack, the command to be used is
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p sgi575 <command>
-
- - Supported command line options are listed below
-
- - <command>
-
- - ``clean``
- - ``build``
- - ``package``
- - ``all`` (all the three above)
-
-
-An example of the command to begin the installation of the Red Hat distribution
-is listed below.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p sgi575 all
-
- - This command cleans, builds and packages the SGI-575 software stack
- needed for the Red Hat installation/boot test for SGI-575 platform.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p sgi575 build
-
- - This command performs an incremental build of the software components
- included in the software stack for the SGI-575 platform. Note: this
- command should be followed by the ``package`` command to complete the
- preparation of the fip image.
-
- - ::
-
- ./build-scripts/build-test-uefi.sh -p sgi575 package
-
- - This command packages the previously build software stack and prepares
- the fip image.
-
-
-Procedure for installing Red Hat distro on SGI-575 platform
------------------------------------------------------------
-
-After the build for the distro is complete, Red Hat can be installed into a
-SATA disk image. Before beginning the installation process, contact Red Hat to
-obtain the RHEL 7.4 DVD installer image for AArch64 platform.
-
-The command used to begin the distro installation is:
-
- ::
-
- cd model-scripts/sgi
- ./distro.sh -p sgi575 -i <iso_image_path> -s <disk size> -a <additional_params> -n [true|false]
-
-Supported command line options are listed below
-
- - -i <iso_image_path>
-
- - Path to the downloaded installer iso image.
-
- - -s <disk_size>
-
- - Size of the SATA disk image (in GB) to be created. 4GB and above is
- good enough for most use cases.
-
- - -n [true|false] (optional)
-
- - Controls the use of network ports by the model. If network ports have
- to be enabled, use 'true' as the option. Default value is set to
- 'false'.
-
- - -a <additional_params>
-
- - Specify any additional model parameters to be passed. The model
- parameters and the data to be passed to those parameters can be found
- in the FVP documentation.
-
-
-An example of the command to begin the boot of the Red Hat distribution is
-listed below.
-
- - ::
-
- ./distro.sh -p sgi575 -i ./RHEL-ALT-7.4-20171030.0-Server-aarch64-dvd1.iso -s 4
-
- - This command creates a 4GB SATA disk image, boot the SGI-575 software
- stack and start the installation of Red Hat distro.
-
- - From here on, follow the instructions of the Red Hat installer. For more
- information about the installation procedure, please refer this
- `link <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/>`_.
-
- - After the installation is completed, the disk image with a random name
- "<number>.satadisk" will be created in model-scripts/sgi/ folder. User
- should use this disk image when booting the Red Hat distribution.
-
-
-Procedure for booting Red Hat distro on SGI-575 platform
---------------------------------------------------------
-
-To boot the Red Hat distro, use the following command:
-
- ::
-
- cd model-scripts/sgi
- ./distro.sh -p sgi575 -d <satadisk_path> -a <additional_params> -n [true|false]
-
-Supported command line options are listed below
-
- - -d <satadisk_path>
-
- - Path to the installed SATA disk image created using the previous
- section.
-
- - -n [true|false] (optional)
-
- - Controls the use of network ports by the model. If network ports have
- to be enabled, use 'true' as the option. Default value is set to
- 'false'.
-
- - -a <additional_params>
-
- - Specify any additional model parameters to be passed. The model
- parameters and the data to be passed to those parameters can be found
- in the FVP documentation.
-
-
-Example command functionality are as listed below.
-
- - ::
-
- ./distro.sh -p sgi575
-
- - This command looks for the available .satadisk image in the
- ``model-scripts/sgi`` folder and boots with that image. If multiple
- .satadisk images are found, it will list them all but won't boot.
-
- - ::
-
- ./distro.sh -p sgi575 -d ./redhat.satadisk
-
- - This command begins the distro boot from the ``redhat.satadisk`` image.
-
-This completes the validation of the Red Hat distribution installation and boot
-functionalities.
-
---------------
-
-*Copyright (c) 2019, Arm Limited. All rights reserved.*
diff --git a/docs/sgi575/how-to/secureboot-test.rst b/docs/sgi575/how-to/secureboot-test.rst deleted file mode 100644 index 379e1ae..0000000 --- a/docs/sgi575/how-to/secureboot-test.rst +++ /dev/null @@ -1,222 +0,0 @@ -How to build SGI-575 platform software to validate Secure Boot -============================================================== - - -.. section-numbering:: - :suffix: . - -.. contents:: - -What is Secure Boot -------------------- - -Secure boot is a mechanism to build and maintain a complete chain of trust on -all the software layers executed in a system and preventing malicious code to be -stored and loaded in place of the authenticated one. When the device starts, the -firmware checks the signature of each piece of boot software, including UEFI -firmware drivers, EFI applications, and the operating system. If the signatures -are valid, the device boots, and the firmware gives control to the operating -system. Fundamental to the success of the secure boot is the ability to securely -store (also referred to as secure storage) and access the keys used for -authentication during the various stages of boot. - -Secure boot and Secure storage mechanisms are defined by the UEFI -specifications. In short, the UEFI specifications define the use of two -asymmetric key pairs, platform key (PK) and Key Exchange Key (KEK), and -databases for valid and black listed signatures. These keys and databases are -used during the secure boot phase which implies that the platform should provide -a tamper proof mechanism to store these keys. - -Secure boot support for SGI-575 platform ----------------------------------------- - -The SGI-575 platform software allows validation of the secure boot process. -Though secure boot process have to be validated using a linux distribution as -the target OS, the SGI platform software stack currently limits this feature -validation to boot of a signed busybox OS. There are pre-requisite packages to -be installed on the host PC to build the disk image to validate the secure boot -process. It is important that the following packages are installed prior to -building of the software stack for secure boot validation. The prerequisite -package installer script, if used, does install these packages as well. - -- efitools git repo is cloned and available at tools/efitools -- sbsign package is installed on to the local host system - -The next step is to create key pairs required for secure boot. The one-time -generation of the following key pairs are mandatory - PK, KEK, DB and DBX. The -following commands can be used to generate these key pairs. - -- Key Pair Creation : PK, KEK, DB and DBX - - :: - - cd tools/efitools - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=PK/" -keyout PK.key -out PK.crt -days 3650 -nodes -sha256 - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=KEK/" -keyout KEK.key -out KEK.crt -days 3650 -nodes -sha256 - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=DB_Key/" -keyout DB.key -out DB.crt -days 3650 -nodes -sha256 - openssl req -new -x509 -newkey rsa:2048 -subj "/CN=DBX_Key/" -keyout DBX.key -out DBX.crt -days 3650 -nodes -sha256 - -- Convert crt certificate to der format - - :: - - openssl x509 -in PK.crt -outform der -out PK.der - openssl x509 -in KEK.crt -outform der -out KEK.der - openssl x509 -in DB.crt -outform der -out DB.der - openssl x509 -in DBX.crt -outform der -out DBX.der - -The signing of the grub and linux images are performed as a part of build script -“build-secureboot.sh”. There is no explicit user action required to sign these -images. - -Procedure to build secure boot test for SGI platforms ------------------------------------------------------ - -The procedure to build the secure boot test along with the SGI-575 platform software -stack is listed below. - -To build the SGI-575 software stack, the command to be used is - - :: - - ./build-scripts/sgi/build-test-secureboot.sh -p sgi575 <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/sgi/build-test-secureboot.sh -p sgi575 all - - - This command cleans, builds and packages the SGI software stack needed - for the secure boot test for SGI-575 platform. - - - :: - - ./build-scripts/sgi/build-test-secureboot.sh -p sgi575 build - - - This command performs an incremental build of the software components - included in the software stack for the SGI-575 platform. Note: this - command should be followed by the 'package' command to complete the - preparation of the fip and the disk image. - - - :: - - ./build-scripts/sgi/build-test-secureboot.shh -p sgi575 package - - - This command packages the previously built software stack and prepares - the fip and the disk image. - - -Procedure to execute secure boot test on SGI platforms ------------------------------------------------------- -The procedure to execute the secure boot test on the SGI platform is listed -below. - - :: - - cd model-scripts/sgi - ./secure_boot.sh -p sgi575 -a <additional_params> -n [true|false] - - -Supported command line options are listed below - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to validate the secure boot functionality are as listed below. - - - :: - - ./secure_boot.sh -p sgi575 - - - This command starts the execution of the SGI-575 model and the software - boots upto the busybox login prompt. - - - :: - - ./secure_boot.sh -p sgi575 -n true - - - This command starts the execution of the SGI-575 model and the - software boots upto the busybox login prompt. The model supports - networking allowing the software running within the model to access - the network. - - - :: - - ./secure_boot.sh -p sgi575 -n true -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the SGI-575 model with networking - enabled and the software boots upto the busybox login prompt. Additional - parameters to the model are supplied using the -a command line - parameter. - -There are additional steps to be performed on the first boot to setup the secure -boot process. These steps are listed below. Ensure that these steps are executed -on the very first boot for validating the secure boot. - -- Interrupt the boot at EDK2 by pressing escape key and dropping into the EDK2 - boot menu. -- Select Device Manger -> Secure Boot Configuration -> Secure Boot Mode → - choose Custom mode and then press enter. -- Select "Custom Secure Boot Options” and then press enter. -- Select “DBX Options” -> "Enroll Signature" then press enter → - "Enroll Signature Using File" and the press enter → Select “NO VOLUME LEBEL” - and then press enter. -- Select EFI and press enter -> select BOOT and press enter → now Select - “DBX.der” and press enter -> “Commit Changes and Exit”. -- Repeat steps “d” and “e” for “DB options” for “DB.der”. -- Repeat steps “d” and “e” for “KEK options” for “KEK.der”. -- Repeat steps “d” and “e” for “PK options” for “PK.der”. -- Press Escape and press F10 to save. Ensure that the “Current Secure Boot - State” is set as “Enabled”. -- Press Escape and select the “continue” option. -- Prompts the user to press the “Enter”. Press Enter key which then reboots the - system -- Make sure to close the model using “Cross Mark” of “Fast Models -Clark” - windows after this, if model does not close then press “ctrl-c” to close it. - -Relaunch the model again, the platform boots up to busybox login prompt with -secure boot enabled. If the authentication of the grub or the linux kernel -fails, the boot fails and the user is notified about the authentication failure. - -To confirm that the boot is indeed a secure boot, the linux kernel messages -can be looked up. The following messages would appear in the linux boot log in -case of a secure linux kernel boot. - - :: - - Loading driver at 0x000F5D26000 EntryPoint=0x000F6D0AF80 - Loading driver at 0x000F5D26000 EntryPoint=0x000F6D0AF80 - EFI stub: Booting Linux Kernel... - EFI stub: UEFI Secure Boot is enabled. - EFI stub: Using DTB from configuration table - EFI stub: Exiting boot services and installing virtual address map... - [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd060] - -This completes the validation of the Secure boot functionality. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/sgi575/how-to/setup-pxe-server.rst b/docs/sgi575/how-to/setup-pxe-server.rst deleted file mode 100644 index 6e9cca0..0000000 --- a/docs/sgi575/how-to/setup-pxe-server.rst +++ /dev/null @@ -1,204 +0,0 @@ -How to setup PXE server on Ubuntu -================================= - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Context -------- - -Preboot Execution Environment (PXE) boot is a standardized server-client -environment to boot an OS remotely through network. This allows multiple client -to install/boot OS remotely from a single server. All major distributions such -as Fedora, Ubuntu, Debian, Red Hat supports PXE boot. The virtio network device -available in the SGI-575 platform can be leveraged to do PXE boot of linux -distributions. Ubuntu in particular allows installation through CDROM or PXE -only. To install Ubuntu on SGI-575 Platform, PXE boot should be used. - -How to setup TFTP server ------------------------- - -Before beginning the installation, on the host PC (sever), TFTP, apache2 and -DHCP servers must be setup. The following steps can be used as reference to -setup the PXE server. - -- Download the required linux distribution network installer for arm64 - architecture. For example, the Ubuntu network installer for arm64 can be - downloaded from `here <http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/current/images/netboot/netboot.tar.gz>`_. - -- Extract the downloaded tar files - - :: - - tar -xvzf netboot.tar.gz - -- Install the TFTP server, DHCP server and dependencies - - :: - - sudo apt-get install apache2 tftpd-hpa inetutils-inetd isc-dhcp-server - -- Configure the PXE server to point the tftpboot directory - - - Open ``/etc/default/tftpd-hpa`` to edit - - :: - - sudo vi /etc/default/tftpd-hpa - - - Append the following lines to the end - - :: - - RUN_DAEMON="yes" - OPTIONS="-l -s /var/lib/tftpboot" - - - Open ``/etc/inetd.conf`` file to edit - - :: - - sudo vi /etc/inetd.conf - - - Append the following line to the end - - :: - - tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot - -- Copy the installer files into the ``/var/lib/tftpboot`` folder - - :: - - sudo cp -fr <ubuntu-installer-path> /var/lib/tftpboot/ - -- Copy the installer files into the apache2 folder - - :: - - sudo mkdir /var/www/html/ubuntu - sudo cp -fr <ubuntu-installer-path> /var/www/html/ubuntu/ - -- Restart the TFTF server - - :: - - sudo systemctl restart tftpd-hpa - -- Check the status of the TFTP server to see if it is active - - :: - - sudo systemctl status tftpd-hpa - - - - If the status is displayed as ``Stopped``, try the following commands - to start the TFTP server again - - :: - - sudo /etc/init.d/inetutils-inetd stop - sudo systemctl restart tftpd-hpa - sudo systemctl status tftpd-hpa - sudo /etc/init.d/inetutils-inetd start - sudo systemctl status tftpd-hpa - -This completes the setup of the TFTP server. - - -How to setup DHCP server ------------------------- - -- Verify whether the DHCP server is stopped - - :: - - sudo systemctl status isc-dhcp-server - - - If the status is shown as ``Running``, the service can be stopped by - using the following command - - :: - - sudo systemctl stop isc-dhcp-server - -- Follow the instructions on `how to create tap interface`_ to setup the tap - interface in the host PC. - -- Configure the DHCP server to point the grub config file (assuming the PXE - server and DHCP server are running on the same pc) - - :: - - sudo vi /etc/dhcp/dhcpd.conf - - - Add the following lines at the end - - :: - - ddns-update-style none; - log-facility local7; - - default-lease-time 600; - max-lease-time 7200; - - authoritative; - allow booting; - allow bootp; - - subnet 192.168.130.0 netmask 255.255.255.0 { - option routers 192.168.130.1; - option subnet-mask 255.255.255.0; - option broadcast-address 192.168.130.255; - option domain-name-servers 10.118.10.61; - option ntp-servers time.nist.gov; - option netbios-name-servers 192.168.130.1; - option netbios-node-type 2; - default-lease-time 86400; - max-lease-time 86400; - range 192.168.130.100 192.168.130.150; - filename "ubuntu-installer/arm64/bootnetaa64.efi"; - } - group { - next-server 10.162.0.155; - host tftp { - filename "ubuntu-installer/arm64/bootnetaa64.efi"; - hardware ethernet 00:02:F7:EF:50:A0; # Check your ethernet mac address - fixed-address 10.162.0.157; - } - } - - -- Add the following lines at the end of ``/etc/default/isc-dhcp-server`` - - :: - - INTERFACES="br0" - INTERFACESv4="br0" - INTERFACESv6="" - -- Restart the DHCP server - - :: - - sudo systemctl restart isc-dhcp-server - - - Check the status of the DHCP server - - :: - - sudo systemctl status isc-dhcp-server - -This completes the PXE setup on the host PC side. Following this, linux -distribution installation can be done through the network. For example, refer -`how to install Ubuntu on SGI-575`_ for the complete installation steps. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - -.. _how to create tap interface: create-tap-interface.rst -.. _how to install Ubuntu on SGI-575: ubuntu-test.rst diff --git a/docs/sgi575/how-to/tftf-test.rst b/docs/sgi575/how-to/tftf-test.rst deleted file mode 100644 index 8e4af1d..0000000 --- a/docs/sgi575/how-to/tftf-test.rst +++ /dev/null @@ -1,140 +0,0 @@ -How to build SGI-575 platform software to execute TF-A Tests -============================================================ - - -.. section-numbering:: - :suffix: . - -.. contents:: - -What are TF-A Tests -------------------- - -The Trusted Firmware-A Tests (TF-A Tests) is a suite of bare metal tests to -exercise the Trusted Firmware-A (TF-A) features from the normal world. -It enables strong TF-A functional testing without dependency on a rich OS. -It mainly interacts with TF-A through its SMC interface. It provides a basis -for TF-A developers to validate their own platform ports and add their own -test cases. - -TF-A Tests on SGI-575 platform ------------------------------- - -TF-A firmware on SGI-575 platform has a significant importance in supporting -multiple features on the SGI-575 platform. For instance, secure partition -manager component of TF-A is used in RAS and PSCI component is used for managing -idle states on the platform. There are many more important uses of TF-A in the -SGI-575 platform software stack. So it becomes imperative that the SGI-575 -platform implementation in TF-A is well tested. TF-A Tests on SGI-575 platform -helps to serve this purpose. - -Tests to Skip -------------- - -The TF-A Test suite supports quite a lot of tests covering various aspects of -the TF-A platform implementation. It is possible to selectively disable the -tests that are not supported by listing those tests in the platform specific -``tests_to_skip.txt`` file. - -System suspend/resume related tests are not supported for SGI-575 platform -as there are no wakeup sources in SGI-575 FVP platforms. So such tests and tests -that fail are currently listed in the ``tests_to_skip.txt`` file and listed -below as well. - -- PSCI STAT/Stats test cases after system suspend -- PSCI System Suspend Validation -- PSCI SYSTEM SUSPEND stress tests - -Procedure to build TF-A Tests for SGI-575 platform --------------------------------------------------- - -The procedure to build the TF-A Test cases along with the SGI-575 platform -software stack is listed below. The components of the SGI-575 platform software -stack that are built is limited to those that provide the ability to execute -the TF-A Tests as a BL33 stage binary (i.e, SCP and TF-A). - -To build the SGI software stack and TF-A Tests, the command to be used is - - :: - - ./build-scripts/build-test-tftf.sh -p sgi575 <command> - -Supported command line options are listed below - - - <command> - - - Supported commands are - - - clean - - build - - package - - all (all the three above) - - -Examples of the build command are - - - :: - - ./build-scripts/build-test-tftf.sh -p sgi575 all - - - This command cleans, builds the required components of the SGI-575 - platform software stack (SCP, TF-A) and TF-A Tests. It then prepares - the FIP image that can be used for executing the tests. - - - :: - - ./build-scripts/build-test-tftf.sh -p sgi575 build - - - This command performs an incremental build of the required software - components in the software stack for the SGI-575 platform and TF-A Tests. - Note: this command should be followed by the 'package' command to - complete the preparation of the FIP image. - - - :: - - ./build-scripts/build-test-tftf.sh -p sgi575 package - - - This command packages the previously built software stack and prepares - the FIP image. - -Procedure to execute TF-A Tests for SGI-575 platform ----------------------------------------------------- - -After the build for the TF-A Tests is complete to execute the TF-A Tests, the -command to be used is - - :: - - cd model-scripts/sgi - ./tftf.sh -p sgi575 -a <additional_params> - - -Supported command line options are listed below - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example commands to execute the TF-A Tests are as listed below. - - - :: - - ./tftf.sh -p sgi575 - - - This command starts the execution of the TF-A Tests on the SGI-575 model - and the results are displayed on the console. - - - :: - - ./tftf.sh -p sgi575 -a "-C board.flash0.diagnostics=1" - - - This command starts the execution of the TF-A Tests on the SGI-575 model - and the results are displayed on the console. Additional parameters to - the model are supplied using the -a command line parameter. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/sgi575/how-to/ubuntu-test.rst b/docs/sgi575/how-to/ubuntu-test.rst deleted file mode 100644 index 6caec9d..0000000 --- a/docs/sgi575/how-to/ubuntu-test.rst +++ /dev/null @@ -1,222 +0,0 @@ -How to build SGI-575 platform software to install and boot Ubuntu distribution -============================================================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Ubuntu distribution boot support --------------------------------- -SGI-575 software stack supports the installation and boot of Ubuntu 18.04 Bionic -distribution. The Ubuntu distribution is installed on a SATA disk and the -installed image can be used for multiple boots. - - -Procedure to build SGI-575 software stack for Ubuntu boot ---------------------------------------------------------- - -The SGI-575 platform software stack has to be first built to prepare for the -Ubuntu distribution installation step. The procedure to execute the SGI-575 -platform stack is listed below. - -To build the SGI-575 software stack, the command to be used is - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 <command> - - - Supported command line options are listed below - - - <command> - - - ``clean`` - - ``build`` - - ``package`` - - ``all`` (all the three above) - - -An example of the command to begin the installation of the Ubuntu distribution -is listed below. - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 all - - - This command cleans, builds and packages the SGI-575 software stack - needed for the Ubuntu installation/boot test for SGI-575 platform. - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 build - - - This command performs an incremental build of the software components - included in the software stack for the SGI-575 platform. Note: this - command should be followed by the ``package`` command to complete the - preparation of the fip image. - - - :: - - ./build-scripts/build-test-uefi.sh -p sgi575 package - - - This command packages the previously build software stack and prepares - the fip image. - - -Procedure for installing Ubuntu distro on SGI-575 platform ----------------------------------------------------------- - -Ubuntu installer supports installation only through a CDROM disk. Hence, the -Ubuntu installation disk (ISO image) cannot be used with the SGI-575 model. As -an alternate, Ubuntu can be installed through the PXE boot with the help of -the network installer which can be downloaded from `here <http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/current/images/netboot/netboot.tar.gz>`_. -Refer the `steps to setup PXE server`_ before beginning the installation. - -The following steps can be followed to begin the installation process. - -Create an empty disk image on which the Ubuntu installation will be done. - - :: - - cd model-scripts/sgi - dd if=/dev/zero of=<disk_image_name>.satadisk bs=1G count=<size in GB> - - - For example, use the following command to create a disk size of 4GB - - :: - - dd if=/dev/zero of=ubuntu_pxe.satadisk bs=1G count=4 - -The command to begin the installation is: - - :: - - ./distro.sh -p sgi575 -d <disk_image_name> -n [true|false] -a <additional_params> - - -Supported command line options are listed below - - - -d <disk_image_path> - - - Path to the created disk image on which Ubuntu will be installed. - - - -n [true|false] - - - Controls the use of network ports by the model. Since this installation - has to be done through the network, this must be set to 'true'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -An example of the command to begin the boot of the Ubuntu distribution is -listed below. - - - :: - - ./distro.sh -p sgi575 -d ./ubuntu_pxe.satadisk -n true - - - This command will start the SGI-575 model and loads the edk2 firmware. - - - After the console reaches loading of Tianocore edk2 firmware, press - escape to enter the UEFI menu and select the Boot Manager option. If - PXE setup is done correctly, you will see an option - ``UEFI PXEv4 (Mac:<random-mac-address>)``. Select the UEFI PXEv4 option - to continue the PXE boot. After few seconds, the model will acquire IP - address and find the tftp sever. - - - The SGI-575 platform supports a total of 8GB of DDR memory out of which - 6GB of memory is located above the 32-bit memory space. The Ubuntu - installation fails if the upper 6GB is enabled. To disable the use of - the upper 6GB, at the grub menu displayed during the installation, - edit the kernel boot parameters as below limiting the DDR memory to - 2032MB (2GB - 16MB) for SATA disk detection. - - :: - - setparams 'Install' - set background_color=black - linux /ubuntu-installer/arm64/linux ---quiet ip=dhcp mem=2032m - initrd /ubuntu-installer/arm64/initrd.gz - - - - - From here on, follow the instructions of the Ubuntu installer. For more - information about the installation procedure, please refer this - `link <https://help.ubuntu.com/lts/installation-guide/arm64/ch06s03.html>`_. - - -Procedure for booting Ubuntu distro on SGI-575 platform -------------------------------------------------------- - -To boot the Ubuntu distro, use the following command: - - :: - - cd model-scripts/sgi - ./distro.sh -p sgi575 -d <satadisk_path> -a <additional_params> -n [true|false] - -Supported command line options are listed below - - - -d <satadisk_path> - - - Path to the installed SATA disk image created using the previous - section. - - - -n [true|false] (optional) - - - Controls the use of network ports by the model. If network ports have - to be enabled, use 'true' as the option. Default value is set to - 'false'. - - - -a <additional_params> - - - Specify any additional model parameters to be passed. The model - parameters and the data to be passed to those parameters can be found - in the FVP documentation. - - -Example command functionality are as listed below. - - - :: - - ./distro.sh -p sgi575 - - - This command looks for the available .satadisk image in the - ``model-scripts/sgi`` folder and boots with that image. If multiple - .satadisk images are found, it will list them all but won't boot. - - - :: - - ./distro.sh -p sgi575 -d ./ubuntu_pxe.satadisk - - - This command begins the distro boot from the ``ubuntu_pxe.satadisk`` - image. - - - During boot, at the grub menu, edit the kernel boot parameters as below for - enabling earlycon output and limiting the DDR memory to 2032MB for - SATA disk detection - - :: - - setparams 'Install' - set background_color=black - linux /ubuntu-installer/arm64/linux mem=2032m earlycon=pl011,0x7ff80000 console=ttyAMA0,115200 - initrd /ubuntu-installer/arm64/initrd.gz - - Save and exit the grub menu. This boot will then continue up to the login - prompt. - - -This completes the validation of the Ubuntu distribution installation and boot -functionalities. - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - -.. _steps to setup PXE server: setup-pxe-server.rst diff --git a/docs/sgi575/user-guide.rst b/docs/sgi575/user-guide.rst index 9b9050b..a586bb9 100644 --- a/docs/sgi575/user-guide.rst +++ b/docs/sgi575/user-guide.rst @@ -1,251 +1,2 @@ -SGI-575 platform user guide -=========================== - - -.. section-numbering:: - :suffix: . - -.. contents:: - - -Introduction ------------- - -SGI (System Guidance for Infrastructure) is a collection of resources to provide -a representative view of typical compute subsystems that can be designed and -implemented using specific generations of Arm IP. SGI-575 in particular is based -on: - - - Server Based System Architecture (SBSAv3) - - 8x Cortex-A75 with private L2 Cache - - DynamIQ with L3 Cache options - - System Level Cache options - - Up to 2x DDR4-3200 (DMC-620) - - Arm Cortex-M7 for System Control Processor (SCP) and - Manageability Control Processor (MCP) - -This document is a user guide on how to setup, build and run the software stack -of SGI-575 on Fixed Virtual Platform. - - -Host machine requirements -------------------------- - -The minimum recommended host PC specification for building the software stack -and running the SGI-575 FVP model is a dual-core processor running at 2GHz with -8GB of RAM. For best performance, use a machine with a quad-core processor -running at 2.6GHz with 16GB of RAM with free hard disk space of at least 64GB. - -The software package has been tested on **Ubuntu 16.04 LTS (64-bit)** and -**Ubuntu 18.04 LTS (64-bit)**. This guide assumes that the user is on either of -this operating system. - - -Repo tool setup ---------------- - -The software stack for SGI-575 is available in multiple git repositories. In -order to simplify downloading the software stack for SGI-575 platform, `repo tool <https://source.android.com/setup/develop/repo>`_ -can be used. This section explains how to setup git and repo tool. - -- Install Git by using the following command - - :: - - sudo apt-get install git - -- Git installation can be confirmed by checking the version - - :: - - git --version - - This should return the git version in a format such as ``git version 2.7.4`` - -- Set name and email address in git - - :: - - git config --global user.name "<your-name>" - git config --global user.email "<your-email@example.com>" - -- Download the repo tool - - :: - - sudo apt-get install repo - -This completes the setup of the repo tool. - - -Syncing the software stack --------------------------- - -The manifest file, which contains the location of all the git repositories of -SGI-575 software stack, is available `here <https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git/>`_. -This section explains how to sync the software stack. - -- Switch to a new folder - - :: - - mkdir sgi575 - cd sgi575 - -- For obtaining the latest *stable* software stack, use the following commands - to sync: - - :: - - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m pinned-sgi575.xml -b refs/tags/<RELEASE_TAG> - repo sync -j $(nproc) --fetch-submodules --force-sync - - Note: The RELEASE_TAG can be found in the release notes, if obtained. If - a release note is not available, or if a RELEASE_TAG is not known, use - "master" as the branch to checkout and pass it as the value to the "-b" - parameter as shown in the commands below. - - :: - - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m pinned-sgi575.xml -b master - repo sync -j $(nproc) --fetch-submodules --force-sync - -- For obtaining the software stack with latest *upstream updates* but which - might not have been fully validated, use the following commands to sync: - - :: - - repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m sgi575.xml -b master - repo sync -j $(nproc) --fetch-submodules --force-sync - -This will download the SGI-575 software stack into the ``sgi575`` folder. - - -Installing prerequisites ------------------------- - -Run the following command to install all the required prerequisites to build the -software stack: - - :: - - sudo ./build-scripts/sgi/install_prerequisites.sh - -It is mandatory to execute this script at least once before build and executing -the software stack. - - -Downloading the GCC toolchain binaries --------------------------------------- - -In addition to the prerequisites installed, gcc toolchain binaries have to be -downloaded and placed at the ``tools/gcc`` folder. Use the following commands -to download and untar the binaries: - - :: - - # Move to the sgi575 software stack directory - cd sgi575 - - # Create a folder for gcc under tools folder - mkdir -p tools/gcc - cd tools/gcc - - # Download and extract the binaries - wget https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/aarch64-linux-gnu/gcc-linaro-6.2.1-2016.11-x86_64_aarch64-linux-gnu.tar.xz - tar -xJf gcc-linaro-6.2.1-2016.11-x86_64_aarch64-linux-gnu.tar.xz - wget https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/arm-linux-gnueabihf/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf.tar.xz - tar -xJf gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf.tar.xz - wget https://armkeil.blob.core.windows.net/developer//sitecore/shell/-/media/Files/downloads/gnu-rm/5_4-2016q3/gcc-arm-none-eabi-5_4-2016q3-20160926-linux,-d-,tar.bz2 - tar -xjf gcc-arm-none-eabi-5_4-2016q3-20160926-linux,-d-,tar.bz2 - -This completes the setup of the GCC toolchain binaries. - - -Obtaining the SGI-575 Fast Model --------------------------------- - -A free version of SGI-575 FVP can be downloaded from the `FVP download page <https://developer.arm.com/products/system-design/fixed-virtual-platforms>`_. -Or, use this `direct link <https://silver.arm.com/download/download.tm?pv=4155978&p=2984141>`_ -to download the compressed file. User can request for the latest version through -the same page or contact arm directly at this email address: `support-connect@arm.com <mailto:support-connect@arm.com>`_. - -To setup the free version of SGI-575 FVP, after obtaining the file from the -above download link, use the following commands to extract and setup the model: - - :: - - # Move to the directory containing the downloaded file - cd <required-path> - - # Create a directory where the downloaded file will be extracted - mkdir fastmodel - - # Extract the tar file to fastmodel foler - tar xvf FM000-KT-00155-r11p1-31rel0.tgz -C fastmodel - - # Setup the SGI-575 FVP - cd fastmodel - ./FVP_CSS_SGI-575.sh - -Follow the instruction in the installer and setup the FVP. Typically, the -installer will ask to create a new folder in the home directory. You can either -install the FVP in the home folder, or in the ``fastmodel/refinfra`` folder -inside the ``sgi575`` folder. If you would like to install in the -``fastmodel/refinfra`` folder, when asked for the install location (see below), -provided the install path as shown below. - - :: - - Where would you like to install to? [default: /home/<user-id>/FVP_CSS_SGI-575]: /home/<some-path>/sgi575/fastmodel/refinfra - - Please answer with one of: 'yes/y' or 'no/n' - '/home/<some-path>/sgi575/fastmodel/refinfra' does not exist, create? [default: yes] - -This should install the SGI-575 FVP in ``sgi575/fastmodel/refinfra/`` -folder. Before launching any scripts from ``model-scripts`` folder, export the -absolute path of the model as an environment variable. - - :: - - export MODEL=<some-path>/sgi575/fastmodel/refinfra/models/Linux64_GCC-4.8/FVP_CSS_SGI-575 - -This completes the steps to obtain the SGI-575 Fast Model. - - -Supported Features ------------------- - -SGI-575 software stack supports number of tests to explore its features. To -begin with, one can start with the busybox boot, and then try installing and -booting various linux distribution. SGI-575 is target for infrastructure -platforms and it supports variety of infrastructure specific features. All the -supported tests are listed below: - - 1. Supported Filesystems: - a. `Busybox`_ - b. `Fedora 27 Enterprise Linux Distribution`_ - c. `Debian 9.8.0 Enterprise Linux Distribution`_ - d. `Ubuntu 18.4 Enterprise Linux Distribution`_ - 2. Supported Tests: - a. `ACS`_ - b. `KVM`_ - c. `RAS`_ - d. `Secure Boot`_ - e. `TFTF`_ - - --------------- - -*Copyright (c) 2019, Arm Limited. All rights reserved.* - - -.. _Busybox: how-to/busybox-boot.rst -.. _Fedora 27 Enterprise Linux Distribution: how-to/fedora-test.rst -.. _Debian 9.8.0 Enterprise Linux Distribution: how-to/debian-test.rst -.. _Ubuntu 18.4 Enterprise Linux Distribution: how-to/ubuntu-test.rst -.. _ACS: how-to/acs-test.rst -.. _KVM: how-to/kvm-test.rst -.. _RAS: how-to/ras-test.rst -.. _Secure Boot: how-to/secureboot-test.rst -.. _TFTF: how-to/tftf-test.rst +SGI-575 platform documentation has been migrated to +https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/tree/master/docs/infra diff --git a/docs/user-guide.rst b/docs/user-guide.rst index 6ae4414..66f75a1 100644 --- a/docs/user-guide.rst +++ b/docs/user-guide.rst @@ -62,6 +62,7 @@ The following platforms support different build systems * Corstone-700 : `Corstone-700 User guide <corstone-700/user-guide.rst>`__ * Cortex A5 DesignStart : `Cortex A5 DesignStart User guide <ca5ds/user-guide.rst>`__ +* Corstone-500 : `Corstone-500 User guide <corstone-500/user-guide.rst>`__ * Total Compute(TC0) : `Total Compute User guide <tc0/user-guide.rst>`__ For Other platforms: @@ -90,6 +91,7 @@ The following platform user guides are maintained in this git repository: - `Neoverse(TM) N1 SDP <n1sdp/run-on-n1sdp.rst>`__ - `Corstone-700 <corstone-700/user-guide.rst>`__ - `Cortex A5 DesignStart User guide <ca5ds/user-guide.rst>`__ +- `Corstone-500 User guide <corstone-500/user-guide.rst>`__ - `Juno Development Board User guide <juno/user-guide.rst>`__ - `Armv8-A Base Platform FVP User guide <basefvp/user-guide.rst>`__ - `System Guidance for Mobile, SGM-775 FVP User guide <sgm775/user-guide.rst>`__ @@ -74,6 +74,7 @@ The following platforms are supported: - `TC2 <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/227/tc2>`__ - `Corstone-700 <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/444/corstone-700>`__ - `Cortex A5 DesignStart <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/447/cortex-a5-designstart>`__ +- `Corstone-500 <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/615/corstone-500>`__ - `Total Compute(TC0) <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/total-compute>`__ The following platforms are also supported, but currently require users to diff --git a/sync_workspace.py b/sync_workspace.py index e98c3b3..4def341 100755 --- a/sync_workspace.py +++ b/sync_workspace.py @@ -1,7 +1,7 @@ #!/usr/bin/env python3 """ - " Copyright (c) 2019, Arm Limited. All rights reserved. + " Copyright (c) 2019-2020, Arm Limited. All rights reserved. " Author: Ash Wilding <ash.wilding@arm.com> " " SPDX-License-Identifier: BSD-3-Clause @@ -585,7 +585,7 @@ ARMPLATDB = { "pdir": "corstone700", "mrel": "???", "tagkey": "CORSTONE-700", - "knowntag": "{tagkey}-2020.02.10", + "knowntag": "{tagkey}-2020.12.10", "build": "yocto", "docs": "docs/{pdir}", "platsw": { @@ -604,6 +604,32 @@ ARMPLATDB = { "fw.platsw", # Hide it from final configuration summary ], }, + + ### Corstone-500 + "500": { + "name": "Corstone-500", + "pdir": "corstone500", + "mrel": "???", + "tagkey": "CORSTONE-500", + "knowntag": "{tagkey}-2020.11.27", + "build": "yocto", + "docs": "docs/{pdir}", + "platsw": { + "manifest": "{pdir}.xml", + }, + "k": "null", + "fs": "null", + "fw": [ + "fw.platsw", + ], + "pb": "null", + "includes": [ + "oc.tfa", "oc.uboot", "oc.pokytiny", + ], + "excludes": [ + "fw.platsw", # Hide it from final configuration summary + ], + }, }, ### DesignStart @@ -642,7 +668,7 @@ ARMPLATDB = { "all": [ "p.board.juno.64b", "p.board.juno.legacy", "p.board.tc2", "p.fvp.v8a.base.64b", "p.fvp.v8a.base.legacy", "p.fvp.v8a.fndn.64b", - "p.fvp.sg.m.775", "p.board.n1sdp", "p.corstone.700", "p.ds.a5", + "p.fvp.sg.m.775", "p.board.n1sdp", "p.corstone.700", "p.ds.a5", "p.corstone.500", ], }, @@ -1072,6 +1098,12 @@ ARMPLATDB = { "priority": 60, }, + ### Poky-Tiny Linux + "pokytiny": { + "name": "Poky-Tiny Linux distribution", + "priority": 60, + }, + ### CMSIS "cmsis": { "name": "Arm CMSIS", |