n1sdp: remove n1sdp platform documentationn1sdp-v2

The n1sdp reference platform documentation has been migrated to
gitlab hosted documentation. The user-guide files now provide the
location of the latest documentation.

Thank you Linaro for your help and hosting the documentation.

Signed-off-by: Deepak Pandey <Deepak.Pandey@arm.com>
Change-Id: I2a8abd110d0f61e2d9ffcb70562110123412c350

11 files changed, 2 insertions, 2065 deletions

diff --git a/Errata-1315703.rst b/Errata-1315703.rst
deleted file mode 100755
index 0027c1c..0000000
--- a/Errata-1315703.rst
+++ /dev/null
@@ -1,33 +0,0 @@
-Errata-1315703 WA disabled in Neoverse N1 SDP
-=============================================
-
-In Trusted Firmware-A, all erratum are disabled by default including the
-1315703. If we want any erratum to be enabled, then we have to explicitly
-enable them in the platform Makefile.
-
-The N1SDP stack disables the workaround for Erratum 1315703 by default,
-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.
-
-N1SDP 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
-TF-A does not provide the interface to dynamically disable the CPU
-performance feature. Therefore, applying the workaround penalizes ALL
-software running on N1SDP, including those that do not require the mitigation.
-
-Disabling Errata-1315703 is meant for performance evaluation purposes ONLY
-and should not be used for software that requires a seccomp computing environment.
-
---------------
-
-*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
diff --git a/LES-PRE-21570v1.0 Neoverse N1 system development platform EULA_windows.txt b/LES-PRE-21570v1.0 Neoverse N1 system development platform EULA_windows.txt
deleted file mode 100755
index 924e935..0000000
--- a/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/Prepare_distro_image_for_N1SDP.rst b/Prepare_distro_image_for_N1SDP.rst
deleted file mode 100755
index 41e32ba..0000000
--- a/Prepare_distro_image_for_N1SDP.rst
+++ /dev/null
@@ -1,243 +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 5.10.12 or above (5.10.12 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**
-
-The Linux Kernel with n1sdp-pcie-quirk patches can be git cloned from `linux repository`_.
-To build the linux kernel image follow the commands given below:
-
-     ::
-
-         $ git clone https://git.linaro.org/landing-teams/working/arm/kernel-release.git
-         $ cd kernel-release
-         $ git checkout --track -b n1sdp-branch remotes/linaro/n1sdp
-         $ export ARCH=arm64
-         $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-
-         $ make defconfig
-         $ make Image
-
-Generated Image name : Image
-
-**Building linux deb package**
-
-Pull and merge the debian patches from ubuntu repository.
-
-     ::
-
-         $ export ARCH=arm64
-         $ git remote add ubuntu-remote "git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack"
-         $ git fetch ubuntu-remote 4f7c72c7abbbb51e20b9909359dcfd672ec30f42
-         $ git checkout FETCH_HEAD -b ubuntu-branch
-         $ git checkout n1sdp-branch
-         $ git merge --no-ff --no-edit ubuntu-branch
-
-NOTE: The UBUNTU COMMIT ID is found from the `ubuntu page`_ which is required to pull the linux debian patches. The commit id version should match with linux kernel version e.g. for 5.10.12 the commit id as mentioned on the page is "4f7c72c7abbbb51e20b9909359dcfd672ec30f42".
-
-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.10.12+_5.10.12+-1_arm64.deb rename it to "linux-image-n1sdp.deb".
-
-Creating Ubuntu Root FS
------------------------------
-
-Download the Ubuntu minimal `root file system image`_.
-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
-        mount -t efivarfs efivarfs /sys/firmware/efi/efivars/
-        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.
-
-.. _linux repository: https://git.linaro.org/landing-teams/working/arm/kernel-release.git/log/?h=n1sdp
-.. _ubuntu page: https://kernel.ubuntu.com/~kernel-ppa/mainline/
-.. _root file system image: http://cdimage.ubuntu.com/ubuntu-base/bionic/daily/current/bionic-base-arm64.tar.gz
-
---------------
-
-*Copyright (c) 2020-2021, Arm Limited. All rights reserved.*
diff --git a/cmn-performance-analysis.rst b/cmn-performance-analysis.rst
deleted file mode 100644
index 568188f..0000000
--- a/cmn-performance-analysis.rst
+++ /dev/null
@@ -1,382 +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 as shown below :
-::
-
-    $ perf stat -a -I 1000 \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x24/ \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x28/ \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x44/ \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x48/
-
-Separate events on the same nodes can be specified as shown below :
-::
-
-    $ perf stat -a -I 1000 \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x24/ \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x28/ \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x44/ \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x48/ \
-        -e arm_cmn/hnf_mc_retries,nodeid=0x24/ \
-        -e arm_cmn/hnf_mc_retries,nodeid=0x28/ \
-        -e arm_cmn/hnf_mc_retries,nodeid=0x44/ \
-        -e arm_cmn/hnf_mc_retries,nodeid=0x48/
-
-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 -a -I 1000 \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x24/ \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x28/ \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x44/ \
-        -e arm_cmn/hnf_mc_reqs,nodeid=0x48/
- 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 -a -I 1000 -e arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/
- #    time                 counts                   unit events
- 1.001019030                  0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (49.92%)
- 2.001297917                  0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (49.61%)
- 3.002325835                  0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (50.35%)
- 4.003352327                  0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (50.15%)
- 5.004378592                  0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (49.65%)
- 6.005297570                  0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (50.04%)
- 7.006323364                  0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (50.35%)
- 8.007349052                  0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (49.75%)
- 9.008374834                  0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (49.74%)
- 10.009297068                 0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (50.35%)
- 11.010322898                 0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (50.05%)
- 12.011349043                 0      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/                                     (49.65%)
-
-
-Calculate read bandwidth from perf measurement:
-::
-
- 84.74e6 rdata 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_wdata_beats,nodeid=0xc/ -I 1000
-
- #    time                 counts                  unit events
- 1.001024520                  0      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 2.002071830                  9      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 3.003109931                  0      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 4.004134740                  9      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 5.005170700                  0      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 6.006232432                  0      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 7.007267874                  9      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 8.008294424                  0      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 9.009329587                  9      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 10.010391542                 0      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 11.011426046                 9      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 12.012453000                 0      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 13.013488283                 9      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 14.014549938                 0      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-2021, Arm Limited. All rights reserved.*
diff --git a/coresight.rst b/coresight.rst
deleted file mode 100755
index edb777c..0000000
--- a/coresight.rst
+++ /dev/null
@@ -1,159 +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:: language
-
-	#include <stdio.h>
-
-	int main()
-	{
-		printf("N1SDP\n");
-
-		return 0;
-	}
-
-2. Disassemble the binary:
-
-   *aarch64-linux-gnu-objdump test.out*
-
-..	code-block:: language
-
-	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-2021, Arm Limited. All rights reserved.*
-
diff --git a/multichip.rst b/multichip.rst
deleted file mode 100755
index a428114..0000000
--- a/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/
-
-.. _user-guide: user-guide.rst
-
-----------
-
-*Copyright (c) 2020-2021, Arm Limited. All rights reserved.*
diff --git a/pcie-sr-iov.rst b/pcie-sr-iov.rst
deleted file mode 100755
index a27d361..0000000
--- a/pcie-sr-iov.rst
+++ /dev/null
@@ -1,53 +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
-
-.. _user-guide: user-guide.rst
-.. _pcie-support: pcie-support.rst
-
-----------
-
-*Copyright (c) 2020-2021, Arm Limited. All rights reserved.*
diff --git a/pcie-support.rst b/pcie-support.rst
deleted file mode 100644
index 36110c4..0000000
--- a/pcie-support.rst
+++ /dev/null
@@ -1,68 +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 implementing workarounds and maintaining these workaround patches to Linux Kernel
-in the `Linaro git repository`_. The patches will be rebased when the Linux kernel is migrated.
-
-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.
-
-.. _Linaro git repository: https://git.linaro.org/landing-teams/working/arm/kernel-release.git/log/?h=n1sdp
-
---------------
-
-*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
-
diff --git a/readme.rst b/readme.rst
deleted file mode 100644
index be4f990..0000000
--- a/readme.rst
+++ /dev/null
@@ -1,100 +0,0 @@
-Arm Reference Platforms
-=======================
-
-.. contents::
-
-Introduction
-------------
-
-Arm produce open source software stacks for a variety of platforms, serving as a
-reference to help enable product development based on Arm IP for a range of
-target markets and applications.
-
-We use these software stacks to demonstrate:
-
-- Integration of multiple open source software components, including firmware,
-  operating systems, applications, and services
-
-- Upstream support for configuring the latest Arm IP
-
-- Software features including secure boot, secure services, power management,
-  and reliability/availablility/serviceability (RAS) error handling
-
-- Alignment with Arm specifications and open source community initiatives
-
-
-Software stacks
----------------
-
-For Armv8-A platforms we provide integrated Linux and Android software stacks.
-
-Mobile segment platforms include:
-
-- SCP-firmware
-- Trusted Firmware-A
-- OP-TEE
-- U-Boot port
-- Android Common Kernel (ACK)
-- Android Open Source Project (AOSP) based distribution with graphics support
-- Yocto build and packaging using Poky filesystem for Total Compute(TC0) platform
-
-Infrastructure segment platforms include:
-
-- SCP-firmware
-- Trusted Firmware-A
-- EDK II UEFI port
-- GRUB loaded distro such as Fedora Enterprise
-- Booting multiple instances of a guest OS using Linux KVM & kvmtool is also
-  supported
-
-Rich IoT segment platforms include:
-
-- Boot-firmware
-- Trusted Firmware-A
-- Mainline Linux kernel
-- Yocto build and packaging using poky tiny filesystem
-
-All platforms also support a basic Linux boot to a BusyBox ramdisk filesystem.
-
-These software stacks are updated and tested as part of a quarterly release and
-are made available to build from source, with prebuilt binaries also being
-available for a limited subset of configurations.
-
-
-Supported platforms
--------------------
-
-The following platforms are supported:
-
-- `Juno <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/303/juno>`__
-- `Neoverse N1 SDP <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/440/neoverse-n1-sdp>`__
-- `Armv8-A Base Platform FVP <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/228/fvps>`__
-- `Armv8-A Foundation Model FVP <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/228/fvps>`__
-- System Guidance for Mobile (SGM): `SGM-775 <https://community.arm.com/developer/tools-software/oss-platforms/w/docs/388/system-guidance-for-mobile-sgm>`__
-- `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
-manually sync the software stack sources:
-
-- Neoverse Reference Design (RD): `RD-N1-Edge <https://developer.arm.com/products/system-design/reference-design/neoverse-reference-design>`__,
-  `RD-E1-Edge <https://developer.arm.com/products/system-design/reference-design/neoverse-reference-design>`__
-
-- System Guidance for Infrastructure (SGI): `SGI-575 <https://developer.arm.com/products/system-design/reference-design>`__
-
-
-Getting started
----------------
-
-Please follow the `user guide <user-guide.rst>`__ to sync, build, and run an
-Arm Reference Platforms software stack.
-
-For questions and discussions, visit `our Arm Community forums <https://community.arm.com/developer/tools-software/oss-platforms/f/dev-platforms-forum>`__.
-
-For additional resources, tutorials, and FAQs, browse the ``docs/`` directory or
-visit `our wiki <https://community.arm.com/developer/tools-software/oss-platforms/w/docs>`__.
-
-For technical support or to provide feedback, please contact us at `support@arm.com <mailto:support@arm.com>`__.
diff --git a/release-notes.rst b/release-notes.rst
deleted file mode 100755
index 3719eb9..0000000
--- a/release-notes.rst
+++ /dev/null
@@ -1,74 +0,0 @@
-Release Notes
-=============
-
-.. section-numbering::
-    :suffix: .
-
-.. contents::
-
-
-Features and Fixes
-------------------
-The tagged N1SDP-2021.05.26 is an incremental bug fix release for the
-tagged N1SDP-2021.04.26 release.
-
-Please refer to the `release notes`_ of N1SDP-2021.04.26 for more
-details on features and fixes available in the release, for CCIX
-accelerator profile please refer to `release link`_.
-
-Bug Fix
-^^^^^^^
-- The --no-uefi-secure-boot option is appended to grub_install in
-  Ubuntu installer.
-
-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,
-  refer to `potential damage`_ page for more information
-
-- Note: The case front panel USB 3.0 ports and & audio jacks are NOT connected/usable.
-  They will be removed on later versions.
-
-Known Issues and Limitations
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- Patches providing proof of concept support for Xilinx CCIX accelerator endpoints are no longer included in this release.
-- 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 DIMMs (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.
-- 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.
-
-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
-
-.. _release link: https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms.git/tree/?h=N1SDP-2020.07.27
-.. _potential damage: https://community.arm.com/developer/tools-software/oss-platforms/w/docs/604/notice-potential-damage-to-n1sdp-boards-if-using-latest-firmware-release
-.. _release notes: https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms.git/tree/release-notes.rst?h=n1sdp-v2&id=a4c9f5147b357f1ef435ea5966e7b6be6aa9b792
-
---------------
-
-*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
diff --git a/user-guide.rst b/user-guide.rst
index 51ff57a..495f95d 100644
--- a/user-guide.rst
+++ b/user-guide.rst
@@ -1,565 +1,3 @@
-User Guide
-==========
+The N1Sdp documentation has been migrated to
+https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/tree/master/docs/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 fetch, build from source, and run an Arm Reference Platforms
-software stack on N1SDP, including a Linux distribution based on either the `Yocto project`_'s Poky
-Linux, or on Ubuntu Server.
-
-The synced workspace includes:
-
- * Scripts to build the board firmware, Linux kernel, and Ubuntu Server distro image
- * Yocto `Bitbake`_ layers for building the Board Support Package (BSP) and Poky Linux distro
- * Other supporting board files and prebuilt binaries.
-
-Prerequisites
--------------
-
-These instructions assume that:
- * Your host PC is running Ubuntu Linux 18.04 LTS and should have at least 50GB free storage space
- * 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 ensure that all the required packages are installed, run:
-
-::
-
-    sudo apt-get update
-    sudo apt-get install chrpath gawk texinfo libssl-dev diffstat wget git unzip gcc-multilib \
-     build-essential socat cpio python python3 python3-pip python3-pexpect xz-utils debianutils \
-     iputils-ping python3-git python3-jinja2 libgl1-mesa-dev libsdl1.2-dev pylint3 xterm git-lfs \
-     openssl curl libncurses5-dev zlib1g-dev python-pip fuseext2 autoconf autopoint
-
-Configure Git, run:
-
-::
-
-    git config --global user.email "you@example.com"
-    git config --global user.name "Your Name"
-
-**Install repo tool**
-
-Follow the instructions provided in the `repo README file`_ to install the ``repo tool``.
-
-NOTE: The repo tool which gets installed using apt-get command sometimes return errors, in such a case it is recommended to install repo using the ``curl`` method:
-
-::
-
-    mkdir -p ~/.bin
-    PATH="${HOME}/.bin:${PATH}"
-    curl https://storage.googleapis.com/git-repo-downloads/repo > ~/.bin/repo
-    chmod a+rx ~/.bin/repo
-
-Syncing and building the source code
-------------------------------------
-
-The N1SDP software stack supports two software distributions:
- * Poky Linux, a minimal BusyBox-like environment
- * Ubuntu Server.
-
-The instructions below provide the necessary steps to sync and build these distributions.
-
-First, create a new folder that will be your workspace and will henceforth be referred to as
-``<n1sdp_workspace>`` in these instructions:
-
-::
-
-    mkdir <n1sdp_workspace>
-    cd <n1sdp_workspace>
-    export N1SDP_RELEASE=refs/tags/N1SDP-2021.05.26
-
-NOTE: Sometimes new features and additional bug fixes will be made available in the git repositories
-and will not yet have been tagged as part of a release. To pickup these latest changes you can drop
-the ``-b <release tag>`` option from the ``repo init`` commands below, however please be aware that
-such untagged changes have not yet been formally verified and should be considered unstable until
-they are tagged in an official release.
-
-To sync BSP without Ubuntu
-##########################
-
-Choose this option if you intend to run the provided Poky Linux distro, or your own alternative
-software solution.
-
-To sync a specific tagged release::
-
-    repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m n1sdp-v2.xml -g bsp -b ${N1SDP_RELEASE}
-    repo sync -j$(nproc)
-
-Or to sync the latest untagged features and bug fixes::
-
-    repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m n1sdp-v2.xml -g bsp
-    repo sync -j$(nproc)
-
-To sync both the BSP and Ubuntu
-###############################
-
-Choose this option if you intend to run the provided Ubuntu Server distro.
-
-To sync a specific tagged release::
-
-    repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m n1sdp-v2.xml -g ubuntu -b ${N1SDP_RELEASE}
-    repo sync -j$(nproc)
-
-Or to sync the latest untagged features and bug fixes::
-
-    repo init -u https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms-manifest.git -m n1sdp-v2.xml -g ubuntu
-    repo sync -j$(nproc)
-
-To build the BSP and Poky Linux distro
-######################################
-
-Mandatory for *all* users.
-
-::
-
-    cd <n1sdp_workspace>/bsp
-    export DISTRO="poky"
-    export MACHINE="n1sdp"
-    source setup-environment
-    bitbake core-image-base
-
-The initial clean build is expected to take a long time, as all host tools and utilities are built
-from source before 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
-``<n1sdp_workspace>/bsp/build-poky/tmp-poky/deploy/images/n1sdp`` directory.
-
-To build the Ubuntu Server distro
-#################################
-
-Only required if intending to run the provided Ubuntu Server distro.
-
-The Ubuntu Server distro image is built using the script provided in
-``<n1sdp_workspace>/ubuntu/build-scripts``.
-
-::
-
-    cd <n1sdp_workspace>/ubuntu
-    ./build-scripts/build-ubuntu.sh <OPTIONS>
-
-    Options that can be passed to script are:
-    <path to build-ubuntu.sh> [OPTIONS]
-    OPTIONS:
-    cleanall           remove all the sources fetched during previous build, removing all binaries from sub folders.
-    clean              remove all binaries from sub folders generated in previous build.
-    build              build linux, linux-firmware, busybox, grub binaries and Ubuntu distribution image
-    package            package all the above listed components into one single Ubuntu grub image
-
-    NOTE: If no option specified then script will execute cleanall, build and package.
-          The final image grub-ubuntu.image can be located in ubuntu/output/n1sdp
-
-
-Provided components
--------------------
-
-Within the Yocto project, each component included in the N1SDP software stack is specified as
-a `Bitbake`_ recipe. The N1SDP recipes are located at ``<n1sdp_workspace>/bsp/layers/meta-arm/``.
-
-**Steps for baking Images from unstaged source code**
-
-Yocto allows modifying the fetched source code of each recipe component in the
-workspace, by applying patches. This is however not a convenient approach for
-developers, since creating patches and updating recipes is time-consuming.
-To make that easier, Yocto provides the devtool utility. devtool creates a
-new workspace, in which you can edit the fetched source code and bake images
-with the modifications
-
-::
-
-    cd <n1sdp_workspace>/bsp
-    MACHINE=n1sdp DISTRO=poky . ./conf/setup-environment
-    # create a workspace for a given recipe component
-    # recipe-component-name can be of:
-    # trusted-firmware-a / scp-firmware / grub-efi / linux-yocto
-    devtool modify <recipe-component-name>
-    # This creates a new workspace for recipe-component-name and fetches source code
-    # into "build-poky/workspace/sources/{trusted-firmware-a,scp-firmware,edk2-firmware,grub-efi,linux-yocto}"
-    # edit the source code in the newly created workspace
-    # build images with changes on workspace
-    # recipe-component-name can be of: scp-firmware / edk2-firmware / grub-efi / linux-yocto
-    bitbake <recipe-component-name>
-
-NOTE : edk2-firmware cannot be built using devtool, kindly refer to the bug report on `bugzilla`_ for more details.
-
-Software Components
-###################
-
-Trusted Firmware-A
-******************
-
-Based on `Trusted Firmware-A`_.
-
-+--------+----------------------------------------------------------------------------------------------------------------+
-| Recipe | <n1sdp_workspace>/bsp/layers/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-n1sdp.inc |
-+--------+----------------------------------------------------------------------------------------------------------------+
-| Files  | * <n1sdp_workspace>/bsp/build-poky/tmp-poky/deploy/images/n1sdp/bl31-n1sdp.bin                                 |
-+--------+----------------------------------------------------------------------------------------------------------------+
-
-
-System Control Processor (SCP)
-******************************
-
-Based on `SCP Firmware`_.
-
-+--------+----------------------------------------------------------------------------------------------------+
-| Recipe | <n1sdp_workspace>/bsp/layers/meta-arm/meta-arm-bsp/recipes-bsp/scp-firmware/scp-firmware-n1sdp.inc |
-+--------+----------------------------------------------------------------------------------------------------+
-| Files  | * <n1sdp_workspace>/bsp/build-poky/tmp-poky/deploy/images/n1sdp/scp_ramfw.bin                      |
-|        | * <n1sdp_workspace>/bsp/build-poky/tmp-poky/deploy/images/n1sdp/scp_romfw.bin                      |
-|        | * <n1sdp_workspace>/bsp/build-poky/tmp-poky/deploy/images/n1sdp/mcp_ramfw.bin                      |
-|        | * <n1sdp_workspace>/bsp/build-poky/tmp-poky/deploy/images/n1sdp/mcp_romfw.bin                      |
-+--------+----------------------------------------------------------------------------------------------------+
-
-
-uefi edk2
-*********
-
-Based on `UEFI edk2`_.
-
-+--------+---------------------------------------------------------------------------------------------+
-| Recipe | <n1sdp_workspace>/bsp/layers/meta-arm/meta-arm-bsp/recipes-bsp/uefi/edk2-firmware-n1sdp.inc |
-+--------+---------------------------------------------------------------------------------------------+
-| Files  | * <n1sdp_workspace>/bsp/build-poky/tmp-poky/deploy/images/n1sdp/uefi.bin                    |
-+--------+---------------------------------------------------------------------------------------------+
-
-
-Linux
-*****
-
-Based on `Linux 5.10 for N1SDP`_.
-
-+--------+-------------------------------------------------------------------------------------------------+
-| Recipe | <n1sdp_workspace>/bsp/meta/recipes-kernel/linux/linux-yocto_5.10.bb                             |
-+--------+-------------------------------------------------------------------------------------------------+
-| Files  | * <n1sdp_workspace>/bsp/build-poky/tmp-poky/deploy/images/n1sdp/Image                           |
-+--------+-------------------------------------------------------------------------------------------------+
-
-
-Poky Linux distribution
-***********************
-
-The layer is based on the `Poky`_ Linux distro, which is itself based on BusyBox and built using
-glibc.
-
-+--------+---------------------------------------------------------------------------------------------------+
-| Recipe | <n1sdp_workspace>/bsp/layers/openembedded-core/meta/recipes-core/images/core-image-base.bb        |
-+--------+---------------------------------------------------------------------------------------------------+
-| Files  | * <n1sdp_workspace>/bsp/build-poky/tmp-poky/deploy/images/n1sdp/core-image-base-n1sdp.wic         |
-+--------+---------------------------------------------------------------------------------------------------+
-
-
-Ubuntu Linux distribution
-*************************
-
-Ubuntu is built as a separate project using the ``build-scripts/``, then booted using the BSP built
-by Yocto. The generated distro image is placed at ``output/n1sdp/grub-ubuntu.img``.
-
-
-Running the software distribution on N1SDP
-------------------------------------------
-
-This section provides steps for:
- * Setting up the N1SDP with the required board firmware
- * Preparing a bootable disk
- * Boot the supported software distributions (Poky Linux or Ubuntu Server).
-
-Setting up the N1SDP
-####################
-
-After powering up or rebooting the board, any firmware images placed on the board's microSD will be
-flashed into either on-board QSPI flash copied into DDR3 memory via the IOFPGA.
-
-**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.
-
-Before 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".
-
-Enter the following command on the MCC console window to ensure time is correctly set. This is
-required in order for the first distro boot to succeed:
-
-      ::
-
-             Cmd> debug
-             Debug> time
-             Debug> date
-             Debug> exit
-
-Update firmware on microSD card
-###############################
-
-The board firmware files are located in ``<n1sdp_workspace/bsp/build-poky/tmp-poky/deploy/images/n1sdp/>``
-after the BSP source build.
-
-Single chip mode::
-
-    n1sdp-board-firmware_primary.tar.gz    : firmware to be copied to microSD of N1SDP board in single chip mode.
-
-Multi chip mode::
-
-    n1sdp-board-firmware_primary.tar.gz    : firmware to be copied to microSD of primary board.
-    n1sdp-board-firmware_secondary.tar.gz  : firmware to be copied to microSD of secondary board.
-
-There are two methods for populating the microSD card:
-   1. The microSD card from the N1SDP can be removed from N1SDP and can be mounted on a host machine
-      using a card reader,
-   2. The USB debug cable when connected to host machine will show the microSD partition on host
-      machine which can be mounted.
-
-      ::
-
-             $> sudo mount /dev/sdx1 /mnt
-             $> sudo rm -rf /mnt/*
-             $> sudo tar --no-same-owner -xzf n1sdp-board-firmware_primary.tar.gz -C /mnt/
-             $> sudo umount /mnt
-
-NOTE: replace ``sdx1`` with the device and partition of the SD card.
-
-Option (2) above is typically preferred, as removing the microSD card requires physical access to
-the motherboard inside the N1SDP's tower case.
-
-Firmware tarball contains iofpga configuration files, SCP, TF-A, and UEFI binaries.
-
-**NOTE**:
-Please ensure to use the recommended PMIC binary. Refer to page `potential-damage`_ for more info.
-
-If a PMIC binary mismatch is detected, a warning message is printed in the MCC console recommending
-the user to switch to appropriate PMIC image. On MCC recommendation *ONLY*, please update the
-``MB/HBI0316A/io_v123f.txt`` file on the microSD using the below commands.
-
-Example command to switch to 300k_8c2.bin from the host PC
-
-      ::
-
-             $> sudo mount /dev/sdx1 /mnt
-             $> sudo sed -i '/^MBPMIC: pms_0V85.bin/s/^/;/g' /mnt/MB/HBI0316A/io_v123f.txt
-             $> sudo sed -i '/^;MBPMIC: 300k_8c2.bin/s/^;//g' /mnt/MB/HBI0316A/io_v123f.txt
-             $> sudo umount /mnt
-
-L3 Cache Enablement
-###################
-
-By default, L3 cache is disabled for use. To enable/disable L3 cache support, follow these steps:
-
-    1. Run USB_ON command to mount the on-board microSD card on the host PC.
-    2. Open the file "MB/HBI0316A/io_v123f.txt".
-    3. For user to enable/disable L3 cache support, edit the SCC BOOT_GPR1 register in the following manner.
-        * To enable L3 cache, update the SOCCON with offset 0x1184 and set the value 0x00000001. The line should now read,
-            ``SOCCON: 0x1184 0x00000001 ; SoC SCC BOOT_GPR1``
-
-        * To disable L3 cache, update the SOCCON with offset 0x1184 and set the value 0x00000000. The line should now read,
-            ``SOCCON: 0x1184 0x00000000 ; SoC SCC BOOT_GPR1``
-    4. Save and close the file.
-
-Boot Poky on N1SDP
-##################
-
-**Preparing a bootable Poky disk**
-
-A bootable disk (USB stick or SATA drive) can be prepared by flashing the image generated from the
-source build. The image will be available at the location
-``<n1sdp_workspace/bsp/build-poky/tmp-poky/deploy/images/n1sdp/core-image-base-n1sdp.wic>``.
-
-This is a bootable GRUB wic image comprising Linux kernel and Poky distro. The partitioning and
-packaging is performed during the build based on the wks file located at
-``<n1sdp_workspace/bsp/layers/meta-arm/meta-arm-bsp/wic/n1sdp-efidisk.wks>``.
-
-Use the following commands to burn the GRUB image to a USB stick or SATA drive:
-
-        ::
-
-             $ lsblk
-             $ sudo dd if=core-image-base-n1sdp.wic of=/dev/sdx conv=fsync bs=1M
-             $ sync
-
-Note: Replace ``/dev/sdx`` with the handle corresponding to your USB stick or SATA drive, as
-identified by the ``lsblk`` command.
-
-**Booting the board with Poky image**
-
-Insert the bootable disk created earlier. Shutdown and reboot the board by issuing the following
-commands to the MCC console:
-
-    ::
-
-             Cmd> SHUTDOWN
-             Cmd> REBOOT
-
-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 the burned disk.
-
-By default the Linux kernel will boot with ACPI, though Device Tree can also be specified::
-
-            *ARM reference image boot on N1SDP (ACPI)
-             ARM reference image boot on Single-Chip N1SDP (Device Tree)
-             ARM reference image boot on Multi-Chip N1SDP (Device Tree)
-
-The system will boot into a base image environment of Poky Linux.
-
-The N1SDP login password is *root*
-
-Boot Ubuntu on N1SDP
-####################
-
-**Preparing a bootable Ubuntu disk**
-
-A bootable disk (USB stick or SATA drive) can be prepared by formatting it with the distro image
-created during source build. The image will be available at the location location
-``<n1sdp_workspace/ubuntu/output/n1sdp/grub-ubuntu.img>``.
-
-This is a bootable GRUB image comprising Linux kernel and an Ubuntu Server 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.
-
-**Booting the board with Ubuntu image**
-
-Insert the bootable disk created earlier and connect the ethernet cable to a working internet
-connection. This is *REQUIRED* on first boot in order to successfully download and install necessary
-Ubuntu packages. Installation will fail if an internet connection is not available.
-
-NOTE: It is also observed that the installation may fail if more than one storage device is
-present on N1SDP, the error log is as shown below:
-
-    ::
-
-             Booting `Install Ubuntu on N1SDP Platform'
-             error: disk `hd1,msdos2' not found.
-             error: you need to load the kernel first.
-
-             Press any key to continue...
-
-             Failed to boot both default and fallback entries.
-
-             Press any key to continue...
-
-Therefore, it is always recommended to have only one storage device on N1SDP on which
-you want to install the Ubuntu software.
-
-Shutdown and reboot the board by issuing the following commands to the MCC console:
-
-    ::
-
-             Cmd> SHUTDOWN
-             Cmd> REBOOT
-
-
-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 the burned disk.
-
-Ubuntu 18.04 will boot in two stages; the first boot is an installation pass, after which a second
-boot is required to actually enter the Ubuntu Server environment.
-
-To reboot the board after the first boot installation pass has completed, from MCC console:
-
-    ::
-
-             Cmd> REBOOT
-
-The system will boot into a minimal Ubuntu 18.04 environment.
-
-Login as user ``root`` with password *root*, and install any desired packages from the console::
-
-            # apt-get install <package-name>
-
-Building Kernel Modules Natively
-********************************
-
-Native building of kernel modules typically requires kernel headers to be installed on the platform.
-However, a bug in deb-pkg currently causes host executables to be packed rather than the target
-executables.
-
-This can be worked around by building and installing the kernel natively on the platform.
-
-Boot the N1SDP board with Ubuntu filesystem and login as root.
-
-    ::
-
-        apt-get install -y git build-essential bc bison flex libssl-dev
-        git clone -b n1sdp http://git.linaro.org/landing-teams/working/arm/kernel-release.git
-        cd kernel-release/
-        mkdir out
-        cp -v /boot/config-5.10.12+  out/.config
-        make O=out -j4
-        make O=out modules_install
-        make O=out install
-        update-grub
-        sync
-
-Reboot the board and when Grub menu appears, select the Advanced Boot Options -> 5.10.12 kernel for
-booting.
-
-.. _potential-damage: https://community.arm.com/developer/tools-software/oss-platforms/w/docs/604/notice-potential-damage-to-n1sdp-boards-if-using-latest-firmware-release
-.. _Yocto project: https://www.yoctoproject.org
-.. _Bitbake: https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html
-.. _Trusted Firmware-A: https://trustedfirmware-a.readthedocs.io/en/latest/
-.. _SCP Firmware: https://github.com/ARM-software/SCP-firmware
-.. _UEFI edk2: https://github.com/tianocore/edk2
-.. _Linux 5.10 for N1SDP: https://git.linaro.org/landing-teams/working/arm/kernel-release.git/log/?h=n1sdp
-.. _Poky: https://www.yoctoproject.org/software-item/poky
-.. _repo README file: https://gerrit.googlesource.com/git-repo/+/refs/heads/master/README.md
-.. _bugzilla: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14141
-
-----------
-
-*Copyright (c) 2020-2021, Arm Limited. All rights reserved.*