docs/n1sdp: remove n1sdp platform documentationHEADmaster

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: Khasim Syed Mohammed <khasim.mohammed@arm.com>
Change-Id: If182b1908c23fe515eed55764d73befdac85a303

10 files changed, 2 insertions, 1882 deletions

diff --git a/docs/n1sdp/Errata-1315703.rst b/docs/n1sdp/Errata-1315703.rst
deleted file mode 100755
index 6b964c4..0000000
--- a/docs/n1sdp/Errata-1315703.rst
+++ /dev/null
@@ -1,29 +0,0 @@
-Errata-1315703 WA disabled in Neoverse N1 SDP
-=============================================
-
-The patch https://git.linaro.org/landing-teams/working/arm/n1sdp-pcie-quirk.git/tree/arm-tf/0001-n1sdp-arm-tf-disable-workaround-for-N1-Erratum-13157.patch
-is applied by default to the N1SDP stack to disable the workaround for Erratum 1315703 so that the N1 CPU
-performance in N1SDP better reflects that of released versions of the N1 for software that does not require mitigation for Spectre Variant 4.
-
-N1DP uses N1 version r1p0, which is affected by Erratum 1315703, which
-is fixed in N1 r3p1.  The workaround for r1p0 disables the CPU performance
-feature of bypassing of stores by younger loads.  This can significantly
-affect performance.  The Erratum is classified "Cat A (Rare)" and requires
-a specific sequence of events to occur.
-
-Disabling this CPU performance feature is also the mitigation for Spectre
-Variant 4 (CVE-2018-3639).  On CPUs that provide the PSTATE.SBSS feature,
-the OS selectively applies the mitigation only to programs that require it,
-leaving the performance of other programs unaffected.  However, N1 r1p0
-does not have the PSTATE.SBSS feature (which is introduced in N1 r3p1), and
-Arm-TF does not provide the interface to to dynamically disable the CPU
-performance feature.  Therefore, applying the workaround penalizes ALL
-software running on N1 SDP, including those that do not require mitigation.
-
-This patch is meant for performance evaluation purposes ONLY and should not
-be used for software that requires a seccomp computing environment.
-
---------------
-
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
-
diff --git a/docs/n1sdp/LES-PRE-21570v1.0 Neoverse N1 system development platform EULA_windows.txt b/docs/n1sdp/LES-PRE-21570v1.0 Neoverse N1 system development platform EULA_windows.txt
deleted file mode 100755
index 924e935..0000000
--- a/docs/n1sdp/LES-PRE-21570v1.0 Neoverse N1 system development platform EULA_windows.txt
+++ /dev/null
@@ -1,272 +0,0 @@
-12 March 2019                CONFIDENTIAL           LES-PRE-21570 SP-Version 1.0

-

-END USER LICENCE AGREEMENT FOR THE SOFTWARE ASSOCIATED WITH THE 

-ARM® NEOVERSE™ N1 SYSTEM DEVELOPMENT PLATFORM 

-

-THIS END USER LICENCE AGREEMENT (“LICENCE”) IS A LEGAL AGREEMENT BETWEEN YOU 

-(EITHER A SINGLE INDIVIDUAL, OR SINGLE LEGAL ENTITY) AND ARM LIMITED ("ARM") 

-FOR THE USE OF THE DELIVERABLES ACCOMPANYING THIS LICENCE. ARM IS ONLY 

-WILLING TO LICENSE THE DELIVERABLES TO YOU ON CONDITION THAT YOU ACCEPT ALL 

-OF THE TERMS IN THIS LICENCE. BY CLICKING “I AGREE” OR BY INSTALLING OR 

-OTHERWISE USING OR COPYING THE DELIVERABLES YOU INDICATE THAT YOU AGREE TO BE 

-BOUND BY ALL THE TERMS OF THIS LICENCE. IF YOU DO NOT AGREE TO THE TERMS OF 

-THIS LICENCE, ARM IS UNWILLING TO LICENSE THE DELIVERABLES TO YOU AND YOU MAY 

-NOT INSTALL, USE OR COPY THE DELIVERABLES, BUT YOU SHOULD PROMPTLY RETURN THE 

-DELIVERABLES TO YOUR SUPPLIER AND ASK FOR A REFUND OF ANY LICENCE FEE PAID.

-

-“Hardware” means the Arm® NeoverseTM N1 System Development Platform, which is 

-comprised of a hardware development board purchased or borrowed directly from 

-Arm or its authorised distributors.

-

-"Deliverables" means any software, firmware, boardfiles, data and 

-documentation accompanying this Licence, any printed, electronic or online 

-documentation supplied with it, and any updates, patches and modifications 

-Arm may make available to you under the terms of this Licence, in all cases 

-relating to the supporting deliverables for the Hardware. 

-

-“Purpose” means the use of the Deliverables solely for the purposes of: (1) 

-your internal development, testing and debugging of software applications 

-that are designed to run solely on microprocessors manufactured under licence 

-from Arm; and (2) prototyping hardware designs incorporating the Deliverables  

-

-

-1.  LICENCE GRANTS.

-DELIVERABLES: Arm hereby grants to you, subject to the terms and conditions 

-of this Licence, a non-exclusive, non-transferable licence solely for use on 

-the Hardware and only for the Purpose to use and copy the Deliverables 

-identified in the Schedule.

-

-You shall not modify the Deliverables. You shall not redistribute or 

-sub-licence any of the Deliverables.

- 

-2.  RESTRICTIONS ON USE OF THE DELIVERABLES.

-COPYING: You shall not use or copy the Deliverables except as expressly 

-authorised in this Licence. You may make one additional copy of the delivered 

-Deliverables media or image for backup or archival purposes.

-

-PERMITTED USERS: The Deliverables shall be used only by your employees, or by 

-your bona fide sub-contractors for whose acts and omissions you hereby agree 

-to be responsible to Arm to the same extent as you are for any acts and 

-omissions of your employees, and provided always that such sub-contractors; 

-(i) work only onsite at your premises; (ii) comply with the terms of this 

-Licence; (iii) are contractually obligated to use the Deliverables only for 

-your benefit, and (iv) agree to assign all their work product and any rights 

-they create therein in the supply of such work to you. Only the single 

-individual, company or other legal entity to whom Arm is supplying this 

-Licence may use the Deliverables. Except as provided in this clause, you 

-shall not allow third parties (including but not limited to any subsidiary, 

-parent or affiliated companies, or offsite contractors you may have) to use 

-the Deliverables unless Arm specifically agrees otherwise with you on a case 

-by case basis.

-

-NO REMOTE USE: The Deliverables shall only be used onsite at your premises 

-and only for your benefit.

-

-MULTIPLE VERSIONS: The media on which the Deliverables resides may contain 

-more than one version of the Deliverables, each of which is compatible with a 

-different operating system (such as Microsoft Windows and Red Hat Linux). 

-

-ACADEMIC OR EDUCATIONAL USERS ONLY: If you or your employer or institution 

-paid academic or educational pricing for the Deliverables, or the 

-Deliverables are identified as an academic or educational version (together 

-“Academic Software”), then notwithstanding anything else in this Licence, YOU 

-AGREE TO USE THE ACADEMIC SOFTWARE ONLY FOR ACADEMIC, NON-COMMERCIAL 

-PURPOSES, AND ARM DOES NOT GRANT YOU ANY RIGHTS TO DISTRIBUTE OR SUB-LICENSE 

-ANY APPLICATIONS DEVELOPED USING THE ACADEMIC SOFTWARE UNDER THIS LICENCE. 

-

-REVERSE ENGINEERING: Except to the extent that such activity is permitted by 

-applicable law you shall not reverse engineer, decompile or disassemble any 

-of the Deliverables. If the Deliverables were provided to you in Europe you 

-shall not reverse engineer, decompile or disassemble any of the Deliverables 

-for the purposes of error correction.

-

-BENCHMARKING: This licence does not prevent you from using the Deliverables 

-for internal benchmarking purposes. However, you shall treat any and all 

-benchmarking data, and any other results of your use or testing of the 

-Deliverables which are indicative of performance, efficacy, reliability or 

-quality, as confidential information and you shall not disclose such 

-information to any third party without the express written permission of Arm. 

-

-RESTRICTIONS ON TRANSFER OF LICENSED RIGHTS: You shall not rent or lease the 

-Deliverables. Except as identified in the “PERMITTED USERS” paragraph above, 

-you shall not share the Deliverables with contractors or third parties. The 

-rights granted to you under this Licence may not be assigned, sublicensed or 

-otherwise transferred by you to any third party without the prior written 

-consent of Arm. An assignment shall be deemed to include, without limitation; 

-(i) any transaction or series of transactions whereby a third party acquires, 

-directly or indirectly, the power to control the management and policies of 

-you, whether through the acquisition of voting securities, by contract or 

-otherwise; or (ii) the sale of more than fifty percent (50%) of the your 

-assets whether in a single transaction or series of transactions.  You shall 

-not rent or lease the Deliverables. You shall not share the Deliverables with 

-contractors (except as identified in the ‘PERMITTED USERS’ clause above) or 

-other third parties.

-

-COPYRIGHT AND RESERVATION OF RIGHTS: The Deliverables are owned by Arm or its 

-licensors and are protected by copyright and other intellectual property laws 

-and international treaties. The Deliverables are licensed not sold. You 

-acquire no rights to the Deliverables other than as expressly provided by 

-this Licence. You shall not remove from the Deliverables any copyright notice 

-or other notice and shall ensure that any such notice is reproduced in any 

-copies of the whole or any part of the Deliverables made by you or your 

-permitted users.

-

-3.  SUPPORT AND MAINTENANCE.

-If you purchased the Deliverables directly from Arm, and you are not 

-receiving them as an update or upgrade or as Academic Software (defined in 

-Clause 2), you are entitled to reasonable support and maintenance for the 

-Deliverables for the period of six (6) months from the date of purchase. The 

-support will be provided on any version of the Deliverables which, at the 

-date of your support request, are either; (a) the current version made 

-generally available by Arm; or (b) the previous version made generally 

-available by Arm at some time during the previous ninety (90) days. 

-

-Support will be provided by telephone, email or other written format 

-designated by Arm, prioritised at Arm’s discretion, and may not be used as a 

-substitute for training or as additional resource for your programming 

-projects.  Maintenance will be provided in the form of upgrades, updates and 

-patch releases to the Deliverables as and when they are made generally 

-available from Arm.  

-

-Arm’s obligation under this Clause 3 is limited to the provision of support 

-and maintenance to you and Arm is under no obligation to provide any support 

-and maintenance to any third parties under this Licence. If you purchase 

-support and maintenance for additional years it will be provided pursuant to 

-this Clause 3 and will be subject to the terms and conditions of this Licence.

-

-If you are receiving the Deliverables as an update, you obtain no rights to, 

-and shall not, install or use the update, as applicable, unless you have 

-first ceased all use of, and deleted your Deliverables for the version of the 

-Deliverables that you are updating or upgrading, as applicable. Future 

-releases of the Deliverables might introduce backward incompatible changes. 

-Please refer to product documentation for the changes in each release and for 

-guidance about compatibility.

-

-If; (i) you obtained the Deliverables from an Arm authorised reseller or 

-other third party; (ii) Deliverables were provided free of charge or for 

-evaluation; or (iii) it is Academic Software, you are not entitled to any 

-support for the Deliverables from Arm, but Arm may, at its sole discretion 

-provide limited support to you. The vendor of the Deliverables may or may not 

-offer support to you for the Deliverables. Please refer to the Technical 

-Support area of http://www.arm.com for contact details for Arm’s support 

-service and (if applicable) other authorised support channels.  Arm shall be 

-under no obligation to provide support in respect of any modifications (where 

-permitted) to the Deliverables.

-

-4.  CONFIDENTIALITY.

-You acknowledge that the Deliverables, any benchmarking data and related 

-information mentioned in Clause 2 contain trade secrets and confidential 

-material, and you agree to maintain them in confidence and apply security 

-measures no less stringent than the measures which you apply to protect your 

-own like information, but not less than a reasonable degree of care, to 

-prevent their unauthorised disclosure and use. Subject to any restrictions 

-imposed by applicable law, the period of confidentiality shall be indefinite. 

-You agree that you shall not use any such information other than in normal 

-use of the Deliverables under the licences granted in this Licence. You agree 

-to allow Arm to (i) disclose your confidential information to subsidiaries of 

-Arm subject to terms and conditions of confidentiality substantially similar 

-to those set out above in this Clause 4; and (ii) inform Arm’s partner; 

-Taiwan Semiconductor Manufacturing Company Ltd, that you have entered into 

-this Licence with Arm.

-

-5.  LIMITED WARRANTIES.

-For the period of ninety (90) days from the date of receipt by you of the 

-Deliverables, Arm warrants to you that (i) the media on which the 

-Deliverables are provided shall be free from defects in materials and 

-workmanship under normal use; and (ii) the Deliverables will perform 

-substantially in accordance with the accompanying documentation (if any). 

-Arm's total liability and your exclusive remedy for breach of these limited 

-warranties shall be limited to Arm, at Arm's option; (a) replacing the 

-defective Deliverables; or (b) using reasonable efforts to correct material, 

-documented, reproducible defects in the Deliverables and delivering such 

-corrected Deliverables to you. Any replacement Deliverables will be warranted 

-for the remainder of the original warranty period or thirty (30) days, 

-whichever is the longer.

-

-EXCEPT AS PROVIDED ABOVE, YOU AGREE THAT THE DELIVERABLES ARE LICENSED “AS 

-IS”, AND THAT ARM EXPRESSLY DISCLAIMS ALL REPRESENTATIONS, WARRANTIES, 

-CONDITIONS OR OTHER TERMS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT 

-LIMITATION THE IMPLIED WARRANTIES OF NON- INFRINGEMENT, SATISFACTORY QUALITY, 

-AND FITNESS FOR A PARTICULAR PURPOSE.

-

-YOU EXPRESSLY ASSUME ALL LIABILITIES AND RISKS, FOR USE OR OPERATION OF 

-SOFTWARE APPLICATIONS, INCLUDING WITHOUT LIMITATION, APPLICATIONS DESIGNED OR 

-INTENDED FOR MISSION CRITICAL APPLICATIONS, SUCH AS PACEMAKERS, WEAPONARY, 

-AIRCRAFT NAVIGATION, FACTORY CONTROL SYSTEMS, ETC. SHOULD THE DELIVERABLES 

-PROVE DEFECTIVE, YOU ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, 

-REPAIR OR CORRECTION.

-

-6.  LIMITATION OF LIABILITY.

-TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL ARM BE 

-LIABLE FOR ANY INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES 

-(INCLUDING LOSS OF PROFITS) ARISING OUT OF THE USE OR INABILITY TO USE THE 

-DELIVERABLES WHETHER BASED ON A CLAIM UNDER CONTRACT, TORT OR OTHER LEGAL 

-THEORY, EVEN IF ARM WAS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

-

-ARM does not seek to limit or exclude liability for death or personal injury 

-arising from ARM's negligence or ARM’s fraud or willful misconduct and 

-because some jurisdictions do not permit the exclusion or limitation of 

-liability for consequential or incidental damages the above limitation 

-relating to liability for consequential damages may not apply to you.

-

-NOTWITHSTANDING ANYTHING TO THE CONTRARY CONTAINED IN THIS LICENCE, BUT 

-SUBJECT TO THE PREVIOUS PARAGRAPH, THE MAXIMUM LIABILITY OF ARM TO YOU IN 

-AGGREGATE FOR ALL CLAIMS MADE AGAINST ARM IN CONTRACT TORT OR OTHERWISE UNDER 

-OR IN CONNECTION WITH THE SUBJECT MATTER OF THIS LICENCE SHALL NOT EXCEED THE 

-GREATER OF; (I) THE TOTAL OF SUMS PAID BY YOU TO ARM (IF ANY) FOR THIS 

-LICENCE; AND (II) $10 USD.  THE EXISTENCE OF MORE THAN ONE CLAIM WILL NOT 

-ENLARGE OR EXTEND THE LIMIT.

-

-7.  THIRD PARTY SOFTWARE.

-The Deliverables may contain open source software, and the use of such open 

-source software is expressly subject to the terms of the applicable 

-license(s) for that open source software. Information about such open source 

-software and applicable open source license(s) accompanies the Software. 

-

-8.  GOVERNMENT END USERS.

-US Government Restrictions: Use, duplication, reproduction, release, 

-modification, disclosure or transfer of the Deliverables is restricted in 

-accordance with the terms of this Licence.

-

-9.  TERM AND TERMINATION.

-This Licence shall remain in force until terminated by you or by Arm. Without 

-prejudice to any of its other rights if you are in breach of any of the terms 

-and conditions of this Licence then Arm may terminate this Licence 

-immediately upon giving written notice to you. You may terminate this Licence 

-at any time. Upon termination of this Licence by you or by Arm: (i) you shall 

-stop using the Deliverables and confidential information and destroy all 

-copies of the Deliverables and confidential information in your possession 

-together with all documentation and related materials; and (ii) Arm’s 

-obligation to provide support and maintenance shall terminate immediately. 

-The provisions of Clauses 4, 6, 7, 8, 9 and 10 shall survive termination of 

-this Licence.

-

-10.  GENERAL.

-This Licence is governed by English law. Except where Arm agrees otherwise 

-in; (i) a written contract signed by you and ARM; or (ii) a written contract 

-provided by Arm and accepted by you, this is the only agreement between you 

-and Arm relating to the Deliverables and it may only be modified by written 

-agreement between you and Arm. This Licence may not be modified by purchase 

-orders, advertising or other representation by any person. If any clause or 

-sentence in this Licence is held by a court of law to be illegal or 

-unenforceable the remaining provisions of this Licence shall not be affected 

-thereby. The failure by Arm to enforce any of the provisions of this Licence, 

-unless waived in writing, shall not constitute a waiver of Arm's rights to 

-enforce such provision or any other provision of this Licence in the future.

-

-The Deliverables provided under this Licence are subject to U.S. export 

-control laws, including the U.S. Export Administration Act and its associated 

-regulations, and may be subject to export or import regulations in other 

-countries. You agree to comply fully with all laws and regulations of the 

-United States and other countries ("Export Laws") to assure that the 

-Deliverables, are not (1) exported, directly or indirectly, in violation of 

-Export Laws, either to any countries that are subject to U.S.A. export 

-restrictions or to any end user who has been prohibited from participating in 

-the U.S.A. export transactions by any federal agency of the U.S.A. 

-government; or (2) intended to be used for any purpose prohibited by Export 

-Laws, including, without limitation, nuclear, chemical, or biological weapons 

-proliferation. 

-

-

-ARM contract references: LES-PRE-21570 

-

diff --git a/docs/n1sdp/Prepare_distro_image_for_N1SDP.rst b/docs/n1sdp/Prepare_distro_image_for_N1SDP.rst
deleted file mode 100755
index f1bb3f6..0000000
--- a/docs/n1sdp/Prepare_distro_image_for_N1SDP.rst
+++ /dev/null
@@ -1,227 +0,0 @@
-Prepare a distro image for N1SDP: Ubuntu 18.04 as an example
-============================================================
-
-
-.. section-numbering::
-    :suffix: .
-
-.. contents::
-
-
-Introduction
-------------
-
-The Neoverse N1 System Development Platform (N1SDP) is an enterprise class reference board based on the Neoverse N1 core.
-This document is a guide on how to prepare a Linux distro image for N1SDP platform taking Ubuntu 18.04 as an example.
-
-All the steps mentioned below are implemented in build-scripts provided with N1SDP Software stack.
-
-Building Linux Images
----------------------
-
-Get Linux version 4.18 or above (5.4.0 used in this example).
-
-Two Linux images are required
-
-- Monolithic Linux image: Used during first boot
-- Linux debian package: Installed by Ubuntu in first boot and used after second boot onwards.
-
-**Building monolithic linux image**
- Apply n1sdp-pcie-quirk patches available inside <workspace/n1sdp-pcie-quirk/linux/>.
- Also available here https://git.linaro.org/landing-teams/working/arm/n1sdp-pcie-quirk.git/tree/linux/
-
-    ::
-         $ export ARCH=arm64
-         $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-
-         $ make defconfig
-         $ make Image
-
-Generated Image name : Image
-
-**Building linux deb package**
-
-Along with the N1SDP Quirk patches get the following 5 patches from https://kernel.ubuntu.com/~kernel-ppa/mainline provided by Ubuntu and required to build linux debian package.Patches version should match with linux kernel version e.g. for 5.4 use patches under https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.4/
-
-Ubuntu Patches:
-        - 0001-base-packaging.patch
-        - 0002-UBUNTU-SAUCE-add-vmlinux.strip-to-BOOT_TARGETS1-on-p.patch
-        - 0003-UBUNTU-SAUCE-tools-hv-lsvmbus-add-manual-page.patch
-        - 0004-debian-changelog.patch
-        - 0005-configs-based-on-Ubuntu-5.4.0-7.8.patch
-
-Build Commands:
-     ::
-
-         $ export ARCH=arm64
-         $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-
-         $ cat debian.master/config/config.common.ubuntu debian.master/config/arm64/config.common.arm64 > $UBUNTU_OUT_DIR/.config
-         $ make oldconfig
-         $ sed -ie 's/CONFIG_DEBUG_INFO=y/# CONFIG_DEBUG_INFO is not set/' .config
-         $ make bindeb-pkg
-
-Generated Image name: linux-image-5.4.0+_5.4.0+-1_arm64.deb rename it to "linux-image-n1sdp.deb"
-
-Creating Ubuntu Root FS
------------------------------
-
-Download the Ubuntu minimal root file system image from
-"http://cdimage.ubuntu.com/ubuntu-base/bionic/daily/current/bionic-base-arm64.tar.gz".
-This image will be extracted and modified to boot a fully fledged Ubuntu 18.04
-distro.
-
-An initramfs is provided containing the necessary firmware and hardware support.
-The initramfs PID 1 should configure the network interface and then
-execute the installation script.
-
-During the first boot an installation script will configure a minimal working
-base-system.
-
-The provided installation script preforms the following tasks:
-
-- Set root as password for root
-- Add 8.8.4.4 and 8.8.8.8 as nameservers
-- Resize the second partion (and file-system) to end of disk
-- Install a minimal set of package with apt-get
-
-
-Content of the provided installation script (assumes that network is up):
-    ::
-
-        #!/bin/sh
-
-        on_exit() {
-            test $? -ne 0 || exit 0
-            echo "something unexpected happend, bailing to a recovery shell!" >&2
-            exec /bin/bash
-        }
-
-        trap "on_exit" EXIT TERM
-
-        set -u
-        set -e
-
-        mount -t proc proc /proc
-        mount -t sysfs sysfs /sys
-        mount -o remount,rw /
-        chown -Rf root:root / || true
-        chmod 777 /tmp
-        PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
-        export PATH
-        apt-get update
-        apt-get install -y \
-        	apt-utils \
-        	grub-efi-arm64 \
-        	ifupdown \
-        	initramfs-tools \
-        	isc-dhcp-client \
-        	kmod \
-        	linux-firmware \
-        	net-tools \
-        	openssh-server \
-        	resolvconf \
-        	sudo \
-        	systemd \
-        	udev \
-        	vim \
-
-        ln -s /dev/null /etc/systemd/network/99-default.link
-        echo "nameserver 8.8.4.4" >> /etc/resolvconf/resolv.conf.d/head
-        echo "nameserver 8.8.8.8" >> /etc/resolvconf/resolv.conf.d/head
-        service resolvconf restart
-        echo "LABEL=Ubuntu-18.04 /  ext4 defaults 0 0" >> etc/fstab
-        echo "LABEL=ESP /boot/efi vfat defaults 0 0" >> etc/fstab
-        mkdir /boot/efi
-        mount /boot/efi
-        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.
-
---------------
-
-*Copyright (c) 2020, Arm Limited. All rights reserved.*
-
diff --git a/docs/n1sdp/cmn-performance-analysis.rst b/docs/n1sdp/cmn-performance-analysis.rst
deleted file mode 100644
index 96c4740..0000000
--- a/docs/n1sdp/cmn-performance-analysis.rst
+++ /dev/null
@@ -1,363 +0,0 @@
-CMN-600 perf example on Neoverse N1 SDP
-=======================================
-The goal of this document is to give a short introduction on CMN-600
-performance analysis on N1SDP.
-This includes driver load verification and Linux perf usage examples.
-
-The examples include examples such as system level cache access and traffic to
-and from PCI-E devices from the view of the interconnect.
-
-.. section-numbering::
-    :suffix: .
-
-.. contents::
-
-
-Support in Arm's Neoverse N1 SDP software release
--------------------------------------------------
-The software support for CMN-600 performance analysis can be divided into three
-components:
-
-* The user space Linux perf tool
-* The Linux kernel arm-cmn driver
-* EDK2 (DSDT table entry)
-
-The default build of the supplied Neoverse software stack will include all
-necessary changes and patches to test and explore CMN-600 performance analysis.
-
-
-CMN-600 Topology and NodeIDs on Neoverse N1 SDP
------------------------------------------------
-The PMUs in CMN-600 are distributed to the nodes of the mesh interconnect.
-NodeType specific events are configured per node.
-Event counting is done by local counters in the XP attached to the node.
-Global counters are in the Debug Trace Controller (DTC).
-The arm-cmn driver uses local/global register pairing to provide 64-bit event
-counters (see "Counter Allocation" section below).
-
-All the nodes are referenced by NodeID and NodeType.
-PMU events must specify the NodeID of the node on which it is to be counted
-using the nodeid= parameter.
-A summary of Node ID can be found the table below.
-For more details contact support (support-subsystem-enterprise@arm.com).
-
-+---------------------------------+-----------+---------+--------------------+
-| Purpose                         | Node Type | Node ID | Event Name         |
-+---------------------------------+-----------+---------+--------------------+
-| System-Level Cache slices (SLC) | HNF       | 0x24    | arm_cmn/hnf        |
-|                                 |           | 0x28    |                    |
-|                                 |           | 0x44    |                    |
-|                                 |           | 0x48    |                    |
-+---------------------------------+-----------+---------+--------------------+
-| PCI_CCIX (Expansion slot 4)     | RND       | 0x08    | arm_cmn/rnid       |
-+---------------------------------+-----------+---------+--------------------+
-| PCI_0 (All other PCI-E)         | RND       | 0x0c    | arm_cmn/rnid       |
-+---------------------------------+-----------+---------+--------------------+
-| Mesh interconnections           | XP        | 0x00    | arm_cmn/mxp        |
-|                                 |           | 0x08    |                    |
-|                                 |           | 0x20    |                    |
-|                                 |           | 0x28    |                    |
-|                                 |           | 0x40    |                    |
-|                                 |           | 0x48    |                    |
-|                                 |           | 0x60    |                    |
-|                                 |           | 0x68    |                    |
-+---------------------------------+-----------+---------+--------------------+
-| Debug Trace Controller          | DTC       | 0x68    | arm_cmn/dtc_cycles |
-+---------------------------------+-----------+---------+--------------------+
-| ACE-lite slave                  | SBSX      | 0x64    | arm_cmn/sbsx       |
-+---------------------------------+-----------+---------+--------------------+
-
-For details on what is connected to PCI_0 check the N1SDP TRM (Figure 2-9
-PCI Express and CCIX system).
-
-Software components
--------------------
-
-Linux perf tool
-###############
-No modifications of ``perf`` source is needed.
-The user can opt to use any perf compatible with the built kernel or use the
-included script ``build-scripts/build-perf.sh`` to build a static linked binary
-from the included kernel source (binary is created as
-``output/n1sdp/build_artifact/perf``).
-
-
-ACPI DSDT modification
-######################
-The Linux driver expects a DSDT entry that describe the location of the CMN-600
-configuration space.
-This is included in the supplied Neoverse software stack.
-
-Linux perf driver (arm-cmn)
-###########################
-The included arm-cmn driver is a work-in-progress.
-A Snapshot of this driver is included in the supplied Neoverse software stack.
-The driver is controller by ``CONFIG_ARM_CMN`` (enabled in default software
-stack build).
-
-Counter Allocation/Limitation
-*****************************
-The arm-cmn driver provides 64-bit event counts for any given event.
-It accomplishes this using a combination of combined-pair local counters (in an
-DTM/XP) and (uncombined) global counters (in the DTC):
-
-* DTM/XP
-    Can provide up to two 32-bit local counters (built from paired 16-bit
-    counters por_dtm_pmevcnt0+1, and 2+3) for events from itself and/or the
-    up-to-2 devices that are connected to its ports.
-
-    Overflows from these counters are sent to its DTC's global counters.
-    This means only up to 2 events from any of the devices connected to an XP
-    can be counted at the same time without sampling.
-
-
-* DTC
-    Each DTC can provide up to 8 global counters (por_dt_pmevcntA .. H).
-    This means only up to 8 events in a DTC domain can be counted at the same
-    time without sampling.
-
-For example, the N1SDP's two PCI-Express root complexes' RND (PCI_CCIX on RND3
-at NodeID 0x8 and PCI0 on RND4 at NodeID 0xC), hang off of the same XP (0,1).
-Only up to 2 RND events from either of the two PCI-E domains can be measured
-simultaneously without sampling; 3 or more will require sampling.
-
-In the following example, we try to measure 4 RND events, but perf is only
-giving 50% sampling time for each count because the events have to share local
-counters in the XP.
-::
-
- $ perf stat -a \
-     -e arm_cmn/rnid_txdat_flits,nodeid=8/ \
-     -e arm_cmn/rnid_txdat_flits,nodeid=12/ \
-     -e arm_cmn/rnid_rxdat_flits,nodeid=8/ \
-     -e arm_cmn/rnid_rxdat_flits,nodeid=12/ \
-     -I 1000
- #           time  counts unit events
-      1.000089438       0      arm_cmn/rnid_txdat_flits,nodeid=8/     (50.00%)
-      1.000089438       0      arm_cmn/rnid_txdat_flits,nodeid=12/    (50.00%)
-      1.000089438       0      arm_cmn/rnid_rxdat_flits,nodeid=8/     (50.00%)
-      1.000089438       0      arm_cmn/rnid_rxdat_flits,nodeid=12/    (50.00%)
-      2.000231897      79      arm_cmn/rnid_txdat_flits,nodeid=8/     (50.01%)
-      2.000231897       0      arm_cmn/rnid_txdat_flits,nodeid=12/    (50.01%)
-      2.000231897       0      arm_cmn/rnid_rxdat_flits,nodeid=8/     (49.99%)
-
-PMU Events
-**********
-``perf list`` shows the perfmon events for the node types that are detected by
-the arm-cmn driver.
-If a node type is not detected, perf list will not show the events for that
-node type.
-::
-
-    # perf list | grep arm_cmn/hnf
-    arm_cmn/hnf_brd_snoops_sent/                       [Kernel PMU event]
-    arm_cmn/hnf_cache_fill/                            [Kernel PMU event]
-    arm_cmn/hnf_cache_miss/                            [Kernel PMU event]
-    arm_cmn/hnf_cmp_adq_full/                          [Kernel PMU event]
-    arm_cmn/hnf_dir_snoops_sent/                       [Kernel PMU event]
-    arm_cmn/hnf_intv_dirty/                            [Kernel PMU event]
-    arm_cmn/hnf_ld_st_swp_adq_full/                    [Kernel PMU event]
-    arm_cmn/hnf_mc_reqs/                               [Kernel PMU event]
-    arm_cmn/hnf_mc_retries/                            [Kernel PMU event]
-    [...]
-
-The perfmon events are described in the CMN-600 TRM in the register description
-section for each node type's perf event selection register (at offset 0x2000 of
-each node that has a PMU).
-
-CMN-600 TRM register summary (links to all of the node types' offset registers).
-    http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100180_0201_00_en/bry1447971081070.html
-
-
-Specifying NodeID to events in perf
-***********************************
-To program the CMN-600's PMUs, the NodeIDs of the components need to be
-specified for each event using a nodeid= parameter.
-Example:
-::
-
-    $ perf stat -a -I 1000 -e arm_cmn/hnf_mc_reqs,nodeid=0x24/
-
-
-Multiple nodes can be specified for an event using bash brace expansion.
-Note the comma after the -e.
-::
-
-    $ perf stat -a -I 1000 \
-        -e,arm_cmn/hnf_mc_reqs,nodeid={0x24,0x28,0x44,0x48}/
-
-
-Separate events on the same nodes with brace expansion should be specified
-using separate -e.
-::
-
-    $ perf stat -a -I 1000 \
-        -e,arm_cmn/hnf_mc_reqs,nodeid={0x24,0x28,0x44,0x48}/ \
-        -e,arm_cmn/hnf_mc_retries,nodeid={0x24,0x28,0x44,0x48}/
-
-Note this form requires the trailing '/' at the end of the event name.
-
-
-Driver verification
--------------------
-To verify that the arm-cmn has successfully loaded different ways:
-
-* Check if any arm_cmn entires is available
-    ::
-
-     $ perf list | grep arm_cmn
-     arm_cmn/dn_rxreq_dvmop/                            [Kernel PMU event]
-     arm_cmn/dn_rxreq_dvmop_vmid_filtered/              [Kernel PMU event]
-     arm_cmn/dn_rxreq_dvmsync/                          [Kernel PMU event]
-     arm_cmn/dn_rxreq_retried/                          [Kernel PMU event]
-     arm_cmn/dn_rxreq_trk_occupancy_all/                [Kernel PMU event]
-     arm_cmn/dn_rxreq_trk_occupancy_dvmop/              [Kernel PMU event]
-     [...]
-
-
-* Sysfs entries
-    ::
-
-     $ ls -x /sys/bus/event_source/devices/arm_cmn/
-     cpumask
-     dtc_domain_0
-     events
-     format
-     perf_event_mux_interval_ms
-     power
-     subsystem
-     type
-     uevent
-
-
-Example
--------
-
-HN-F PMU
-########
-Make sure to issue some memory load operation(s) in parallel, such as
-memtester, while executing the following perf example.
-
-Memory Bandwidth using hnf_mc_reqs
-**********************************
-Measure memory bandwidth using hnf_mc_reqs; assumes bandwidth comes from SLC
-misses.
-::
-
- $ perf stat -e,arm_cmn/hnf_mc_reqs,nodeid={0x24,0x28,0x44,0x48}/ -I 1000 -a
- 2.000394365        121,713,206      arm_cmn/hnf_mc_reqs,nodeid=0x24/
- 2.000394365        121,715,680      arm_cmn/hnf_mc_reqs,nodeid=0x28/
- 2.000394365        121,712,781      arm_cmn/hnf_mc_reqs,nodeid=0x44/
- 2.000394365        121,715,432      arm_cmn/hnf_mc_reqs,nodeid=0x48/
- 3.000644408        121,683,890      arm_cmn/hnf_mc_reqs,nodeid=0x24/
- 3.000644408        121,685,839      arm_cmn/hnf_mc_reqs,nodeid=0x28/
- 3.000644408        121,682,684      arm_cmn/hnf_mc_reqs,nodeid=0x44/
- 3.000644408        121,685,669      arm_cmn/hnf_mc_reqs,nodeid=0x48/
-
-
-Generic bandwith formula:
-::
-
- hnf_mc_reqs/second/hnf node  * 64 bytes = X MB/sec
-
-Subsitute with data from perf output:
-::
-
- (121713206 + 121715680 + 121712781 + 121715432) * 64 = 29715 MB/sec
-
-
-
-PCI-E RX/TX bandwidth
-#####################
-The RN-I/RN-D events are defined from the perspective of the bridge to the
-interconnect, so the "rdata" events are outbound writes to the PCI-E device
-and "wdata" events are inbound reads from PCI-E.
-
-Measure RND (PCI-E) bandwidth to/from NVMe SSD when running fio
-***************************************************************
-The NVMe SSD (Optane SSD 900P Series) is on PCI-E Root Complex 0 (PCI0, the
-Gen3 slot, behind the PCI-E switch).
-
-Run ``fio`` to read from NVME SSD using 64KB block size for 1000 seconds in
-one terminal:
-::
-
- $ fio \
-     --ioengine=libaio --randrepeat=1 --direct=1 --gtod_reduce=1 \
-     --time_based --readwrite=read --bs=64k --iodepth=64k --name=r0 \
-     --filename=/dev/nvme0n1p5 --numjobs=1 --runtime=10000
- r0: (g=0): rw=read, bs=(R) 64.0KiB-64.0KiB, (W) 64.0KiB-64.0KiB, (T) 64.0KiB-64.0KiB, ioengine=libaio, iodepth=65536
- fio-3.1
- Starting 1 process
- ^Cbs: 1 (f=1): [R(1)][0.5%][r=2586MiB/s,w=0KiB/s][r=41.4k,w=0 IOPS][eta 16m:35s]
- fio: terminating on signal 2
-
- r0: (groupid=0, jobs=1): err= 0: pid=1443: Thu Dec 19 12:12:10 2019
-    read: IOPS=41.3k, BW=2581MiB/s (2706MB/s)(12.3GiB/4894msec) <------------------------------- read bandwidth = 2706 MB/sec
-    bw (  MiB/s): min= 2276, max= 2587, per=98.10%, avg=2532.02, stdev=125.43, samples=6
-    iops        : min=36418, max=41392, avg=40512.33, stdev=2006.90, samples=6
-   cpu          : usr=3.15%, sys=35.15%, ctx=16686, majf=0, minf=1049353
-   IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
-      submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
-      complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1%
-      issued rwt: total=202101,0,0, short=0,0,0, dropped=0,0,0
-      latency   : target=0, window=0, percentile=100.00%, depth=65536
-
- Run status group 0 (all jobs):
-    READ: bw=2581MiB/s (2706MB/s), 2581MiB/s-2581MiB/s (2706MB/s-2706MB/s), io=12.3GiB (13.2GB), run=4894-4894msec
-
- Disk stats (read/write):
-   nvme0n1: ios=202009/2, merge=0/19, ticks=4874362/51, in_queue=3934760, util=98.06%
-
-Measure with ``perf`` in an other terminal.
-Measure rdata/wdata beats.  Each beat is 32 bytes.
-::
-
- $ perf stat -e,arm_cmn/rnid_s0_{r,w}data_beats,nodeid=0xc/ -I 1000 -a
- 3.000383383            248,145      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/
- 3.000383383         84,728,162      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 4.000522271            248,199      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/
- 4.000522271         84,743,908      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 5.000680779            248,209      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/
- 5.000680779         84,746,976      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 6.000835927            247,899      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/
- 6.000835927         84,417,098      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
-
-Calculate read bandwidth from perf measurement:
-::
-
- 84.74e6 wdata beats * 32 bytes per beat = 2711 MB/sec
-
-Measure RND (PCI-E) bandwidth from Ethernet NIC
-***********************************************
-``netperf`` is executed on the N1SDP to generate network traffic.
-
-``netperf`` executing in on terminal...
-::
-
- $ netperf -D 10 -H remote-server-in-astlab -t TCP_MAERTS -l 0
- Interim result:  941.52 10^6bits/s over 10.000 seconds ending at 1576269135.608
- Interim result:  941.52 10^6bits/s over 10.000 seconds ending at 1576269145.608
- Interim result:  941.52 10^6bits/s over 10.000 seconds ending at 1576269155.608
- Interim result:  941.52 10^6bits/s over 10.000 seconds ending at 1576269165.608
-
-...and ``perf`` in an other at the same time.
-::
-
- $ perf stat -e,arm_cmn/rnid_s0_{r,w}data_beats,nodeid=0xc/ -I 1000 -a
- 12.001904404            308,803      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/
- 12.001904404          4,024,328      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 13.002047284            308,994      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/
- 13.002047284          4,024,287      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 14.002233364            309,035      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/
- 14.002233364          4,024,470      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
- 15.002390125            309,162      arm_cmn/rnid_s0_rdata_beats,nodeid=0xc/
- 15.002390125          4,024,376      arm_cmn/rnid_s0_wdata_beats,nodeid=0xc/
-
-Calculate bandwidth from perf measurement:
-::
-
- 4.024e6 wdata beats/second * 32 bytes/beat * 8 bits/byte = 1030e6 bits/second
-
-
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
diff --git a/docs/n1sdp/coresight.rst b/docs/n1sdp/coresight.rst
deleted file mode 100755
index 8744c3b..0000000
--- a/docs/n1sdp/coresight.rst
+++ /dev/null
@@ -1,160 +0,0 @@
-CoreSight support on Neoverse N1 SDP
-====================================
-
-.. section-numbering::
-    :suffix: .
-
-.. contents::
-
-
-CoreSight Introduction
-----------------------
-CoreSight Debug and Trace components are invariably described in a graph-like
-topology which describes the port connections amongst the various components.
-The topology includes, but is not limited to, the following major components.
-
-* ETM(s)
-* ETF(s)/ETB(s)
-* Dynamic/Static Funnel(s)
-* Dynamic/Static Replicator(s)
-* TPIU(s)/ETR(s)
-
-In CoreSight terminology, a component can be roughly described as a source -
-that produces/generates the debug & trace data, and/or a sink - that consumes/stores
-the data, or a link - which routes the data.
-Depending on the "type" of component, it may have 1 or more input port(s),
-1 or more output port(s), a single input port only, or a single output port only.
-
-For instance -
-
-* ETM is a source component which only has a single output port.
-* TPIU/ETR is a sink component which only has a single input port.
-* Funnel is a link component which can be thought of as a MUX having multiple
-  input ports and a single output port.
-* Replicator is a link component which can be thought of as a DEMUX having a single
-  input port and multiple output ports.
-* ETF is a link component which can act both as a source and a sink (it has a
-  FIFO buffer to store the data) and thus has a single input and a single output port.
-
-Refer to `CoreSight_Technical_Introduction`_ for more information about
-CoreSight Debug and Trace elements.
-
-It is worth mentioning that all static components in CoreSight world are not
-addressable and only facilitate intermediate connections between the other
-non-static/Dynamic CoreSight components. They are, however, described in the
-DT/ACPI and get discovered by their respective kernel drivers.
-
-CoreSight components can be described either/both in a device tree or/and in a
-DSDT table within ACPI - similar to other components/peripherals, to get
-enumerated by the Linux kernel.
-
-Every CoreSight component has a corresponding kernel driver which takes care of
-its initialization. There are configuration changes required in the kernel to
-build the appropriate CoreSight components' drivers.
-
-Upon a successful probe of a CoreSight component driver, the particular
-component gets enumerated under ``/dev`` and appears under ``/sys/bus/coresight/devices/``
-in the booted kernel.
-
-Enabling CoreSight on N1SDP
----------------------------
-
-* ACPI bindings:
-
-	CoreSight topology for N1SDP has been described as a _DSD graph within DSDT
-	table for N1SDP package - the support is enabled by default.
-
-
-* Linux Kernel:
-
-	The default configuration for the kernel is to build without the CoreSight drivers.
-	The build flag to enable CoreSight kernel configuration options to build CoreSight
-	kernel drivers is ``LINUX_CORESIGHT_BUILD_ENABLED`` which is set to ``0`` by default.
-	Modify the file ``n1sdp`` under ``build_scripts/platforms/n1sdp`` by setting
-	``LINUX_CORESIGHT_BUILD_ENABLED`` to ``1`` from its default ``0``.
-
-Verifying CoreSight support
----------------------------
-
-Assuming the kernel has been built with the CoreSight configuration, the booted
-kernel should have CoreSight components enumerated under sysfs within
-``/sys/bus/coresight/devices/``. The components should also be seen listed under ``/dev``.
-
-Running perf with CoreSight
----------------------------
-
-CoreSight framework has been integrated with the standard perf core in the kernel
-to assist with trace capturing and decoding. To exercise this, perf needs to be
-built with openCSD (Open CoreSight Decoding) library support.
-
-Execute the following script to build the perf executable with open CSD library
-
-		::
-
-		./build-scripts/build-perf.sh
-
-This will generate the perf executable in the output/n1sdp/build_artifact/ directory which
-can then be transferred to the kernel running on the N1SDP board.
-
-Here's an example showcasing trace capture and decode of a simple application:
-
-1. Build the demo application code:
-
-   *aarch64-linux-gnu-gcc -static -o test main.c*
-
-..	code-block::
-
-	#include <stdio.h>
-
-	int main()
-	{
-		printf("N1SDP\n");
-
-		return 0;
-	}
-
-2. Disassemble the binary:
-
-   *aarch64-linux-gnu-objdump test.out*
-
-..	code-block::
-
-	0000000000400580 <main>:
-	400580:	a9bf7bfd 	stp	x29, x30, [sp,#-16]!
-	400584:	910003fd 	mov	x29, sp
-	400588:	90000000 	adrp	x0, 400000 <_init-0x3b0>
-	40058c:	9118e000 	add	x0, x0, #0x638
-	400590:	97ffffa4 	bl	400420 <puts@plt>
-	400594:	52800000 	mov	w0, #0x0
-	400598:	a8c17bfd 	ldp	x29, x30, [sp],#16
-	40059c:	d65f03c0 	ret
-
-3. Trace the application from the start address ``0x400580`` to ``0x4006f0``
-
-   *./perf record -e cs_etm/@tmc_etr0/u --filter 'start 0x400580@test, stop 0x4006f0@test' --per-thread ./test*
-
-   This step will generate *perf.data* in the current working directory.
-
-4. Decode the trace data with perf
-
-   *./perf report --stdio --dump*
-
-   This step will dump all the captured trace data on stdio.
-
-Refer to the man page of ``perf-record`` for more information on perf options, filters, etc.
-
-References
-----------
-
-- http://infocenter.arm.com/help/topic/com.arm.doc.epm039795/coresight_technical_introduction_EPM_039795.pdf?_ga=2.263237196.1385850732.1581332707-419757503.1576059061
-- http://infocenter.arm.com/help/topic/com.arm.doc.101489_0000_01_en/arm_neoverse_n1_system_development_platform_technical_reference_manual_101489_0000_01_en.pdf
-- https://www.linaro.org/blog/stm-and-its-usage/
-
-
-.. _CoreSight_Technical_Introduction: http://infocenter.arm.com/help/topic/com.arm.doc.epm039795/coresight_technical_introduction_EPM_039795.pdf?_ga=2.263237196.1385850732.1581332707-419757503.1576059061
-
---------------
-
-
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
-
diff --git a/docs/n1sdp/multichip.rst b/docs/n1sdp/multichip.rst
deleted file mode 100755
index 369fd4c..0000000
--- a/docs/n1sdp/multichip.rst
+++ /dev/null
@@ -1,117 +0,0 @@
-Multichip SMP boot on Neoverse N1 SDP with CCIX
-===============================================
-
-.. section-numbering::
-    :suffix: .
-
-.. contents::
-
-
-Introduction
-------------
-The Neoverse N1 System Development Platform (N1SDP) supports dual socket operation wherein
-two N1SDP boards are connected over a CCIX enabled PCIe link. One board is designated as the
-master board whose CCIX enabled PCIe controller is configured in root port mode and the other
-board is configured as slave board whose CCIX enabled PCIe controller is configured in
-endpoint mode. Linux boots in the master board and powers ON the slave board cores such that
-the operating system sees CPU cores and memories from both master and slave boards in separate
-NUMA nodes making a dual socket SMP configuration.
-
-Note:
-Only cores and DDR memory from slave chip are exposed to the operating system. No I/O peripherals
-from slave chip are exposed to the operating system.
-
-Connection Details
-------------------
-For the purpose of connecting two N1SDP boards over PCIe link, a specialized PCIe riser card
-(Part No: V2M-N1SDP-0343A) has to be used. The riser card package includes two PCIe form factor
-riser cards, two high speed low latency PCIe cables and one USB cable (for PCIe REFCLK).
-A 20-pin flat ribbon cable that comes along with N1SDP board accessories should also be used. This
-is used for I2C connection between master and slave board SCP & MCP and other timer synchronization
-handshake signals.
-Setup has to be made following the steps given below:
-
-    1. Designate one N1SDP board as master board and the other N1SDP board as slave board.
-    2. Ensure that both board are powered off.
-    3. Plug in the riser cards, one in each board, in the CCIX slot (the last x16 PCIe slot
-       close to the edge of the board).
-    4. Connect the high speed PCIe cables between the riser cards in respective slots
-       (make one to one connection and not criss-cross connection).
-    5. Connect the USB cable between the riser cards.
-    6. Connect the 20-pin flat ribbon cable between the boardsto the connector named as 'C2C'
-       which should be in the back side of the board.
-    7. Connect the USB/SATA boot media to the respective slot in the master board.
-
-Board Files Setup
------------------
-    1. Power ON the master board and open the MCC console of master board using a terminal
-       application (like minicom or putty).
-    2. Run USB_ON command which mounts the micro SD card content of master board in host machine.
-    3. Assuming the micro SD card is mounted with the name 'MASTER' in host. Open the file
-       MASTER/MB/HBI0316A/board.txt file and note the APPFILE name. It should be like 'io_v123f.txt'
-       or similar.
-    4. Now close the board.txt file and open the io_v123f.txt (the one noted in step 3) which will
-       be in the same folder.
-    5. Set the C2C_ENABLE flag as TRUE and C2C_SIDE flag as MASTER.
-    6. Set the SCC PLATFORM_CTRL register to enable multichip mode and CHIPID=0. For this, uncomment
-       the SOCCON with offset 0x1170 and set the value 0x00000100
-       The line should now read: **SOCCON: 0x1170 0x00000100 ; SoC SCC PLATFORM_CTRL**
-    7. Save and close the file. If the host is Linux run a 'sync' command in one of the terminals to
-       be safe.
-    8. Repeat from step 1 to 4 for slave board. Let's assume host has mounted the slave board's
-       micro SD card with name 'SLAVE'.
-    9. Set the C2C_ENABLE flag as TRUE and C2C_SIDE flag as SLAVE.
-    10. Set the PLATFORM_CTRL register to enable multichip mode and CHIPID=1. For this, uncomment
-        the SOCCON with offset 0x1170 and set the value 0x00000101. Save and close the file. Run
-        sync command in case of Linux host.
-        The line should now read: **SOCCON: 0x1170 0x00000101 ; SoC SCC PLATFORM_CTRL**
-
-Booting the Setup
------------------
-    1. Copy all the firmware binaries to SOFTWARE folder in both master and slave board's micro SD
-       card. Run sync command in case of Linux host. Note that uefi.bin file is not required to be
-       copied to slave micro SD card as UEFI will be run only in the master chip.
-       For getting the sources and building the binaries please refer to `user-guide`_
-    2. Shutdown both the boards.
-    3. Reboot the slave board first and let it boot. Then reboot the master board. This is done
-       because the SCP firmware running in master board expects the slave board to respond to the
-       I2C command when it boots. If the slave board is not responding for the I2C command then
-       master assumes that it is running in single chip environment and continues to boot in single
-       chip mode. This is explicitly done to avoid any delays in waiting for slave to respond that
-       will affect single chip environment where there is no slave connected at all.
-    4. If master SCP finds a slave connected and responding then master SCP will perform several
-       handshakes with slave SCP to bring-up the CCIX link and boot the slave chip's cores.
-
-After Booting
--------------
-    1. UEFI's Dynamic ACPI framework exposes both master and slave chip's processors and memories to
-       Linux. Assuming 16GB DDR memory connected each on master and slave boards, Linux will see
-       8 cores (4 cores in master chip + 4 cores in slave chip) and 32GB DDR memory space.
-    2. Once Linux has booted, /proc/cpuinfo and /proc/meminfo can be dumped to see the total core
-       and memory information that Linux currently sees.
-    3. Also the slave board resources (slave CPUs and slave DDR memory) is treated as separate NUMA
-       node in Linux which can be seen using the numactl --hardware command.
-
-Limitations
------------
-    1. Though the multichip high speed connection is made using CCIX enabled PCIe controllers which
-       supports GEN4 speed, only GEN3 speed has been validated for multichip operation. This affects
-       the cross-chip memory access latency.
-    2. The timer synchronization internal logic doesn't accounted for the external sync signals pad
-       timings. So the PIK clock for timer synchronization module has to be reduced to 150MHz from
-       actual 800MHz.
-    3. The REFCLK counter values on both master and slave chips has to be reset before starting the
-       synchronization process.
-    4. Timer synchronization interrupt flag has no information on the source of interrupt. So
-       synchronization is retriggered everytime an interrupt was hit.
-
-References
-----------
-- http://infocenter.arm.com/help/topic/com.arm.doc.101489_0000_01_en/arm_neoverse_n1_system_development_platform_technical_reference_manual_101489_0000_01_en.pdf
-- https://www.ccixconsortium.com/ccix-library/
-
-----------
-
-*Copyright (c) 2020, Arm Limited. All rights reserved.*
-
-.. _user-guide: user-guide.rst
diff --git a/docs/n1sdp/pcie-sr-iov.rst b/docs/n1sdp/pcie-sr-iov.rst
deleted file mode 100755
index ceeb48f..0000000
--- a/docs/n1sdp/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
-
-----------
-
-*Copyright (c) 2020, Arm Limited. All rights reserved.*
-
-.. _user-guide: user-guide.rst
-.. _pcie-support: pcie-support.rst
diff --git a/docs/n1sdp/pcie-support.rst b/docs/n1sdp/pcie-support.rst
deleted file mode 100644
index bffa7e5..0000000
--- a/docs/n1sdp/pcie-support.rst
+++ /dev/null
@@ -1,70 +0,0 @@
-PCIe support on Neoverse N1 SDP
-===============================
-
-.. section-numbering::
-    :suffix: .
-
-.. contents::
-
-
-Support for PCIe in Arm's Neoverse N1 SDP software releases
------------------------------------------------------------
-The supplied Neoverse software stack includes support for PCIe. However there are
-two issues (detailed below) with the PCIe root port hardware IP present on
-Neoverse N1 SDP. These impact generic code in EDK II UEFI and Linux.
-
-Arm is maintaining patches and implementing workarounds in the following Linaro
-git repository: http://git.linaro.org/landing-teams/working/arm/n1sdp-pcie-quirk.git/
-The patches will be regularly rebased so that they apply cleanly to the relevant
-components (SCP-firmware, mainline Linux, and upstream EDK II UEFI).
-The git repository also provides a shell script, patch_apply.sh.
-
-The patches are applied automatically as part of the Arm reference platform software
-workspace sync process, providing a software stack with full PCIe support. However, note that
-it is not possible to use an unmodified Linux distribution release on Neoverse N1SDP,
-without patching and rebuilding the kernel shipped with that distribution.
-
-
-SLVERR on PCIe device and function enumeration
---------------------------------------------------
-Linux and EDK II UEFI use standardised PCIe enumeration code based
-on the assumption that PCIe compliant root ports must return magic number 0xFFFFFFFF
-when either a device is not connected or a function is not implemented.
-The PCIe root port hardware IP on Neoverse N1 SDP boards instead asserts
-an AXI SLVERR response, triggering a bus fault on the applications processor
-performing PCIe enumeration.
-
-A software workaround has been implemented in the System Control Processor (SCP)
-that performs minimal PCIe enumeration and generates a bus/device/function (BDF)
-table that it places in shared Non-secure SRAM. During this minimal enumeration,
-the SCP ignores any bus faults from accessing PCIe configuration space,
-effectively suppressing the non-compliant AXI SLVERR responses generated by the
-PCIe root port hardware IP. Patches have also been applied to EDK II UEFI and Linux
-to use the generated BDF table during their own PCIe enumeration routines.
-
-Non-contiguous configuration space
-----------------------------------
-Linux and EDK II UEFI use standardised PCIe enumeration code based on the assumption
-that the PCIe Enhanced Configuration Access Mechanism (ECAM) base address is the same
-as the base address of the root port's configuration space. These assumptions are not
-valid for N1SDP leading to issues identifying the root port during PCIe enumeration.
-
-A software workaround has been added to the SCP that inserts the base address of the
-PCIe root port's configuration space as the first word in the BDF table in shared
-Non-secure SRAM in both EDK II UEFI and Linux. The generic PCIe code has been patched to
-read the base address of the PCIe root port configuration space from the BDF table;
-this base address is then automatically used whenever a given BDF is all zeroes.
-
-PCIE Root Port config space supports only 32 bits R/W
------------------------------------------------------
-
-The root port configuration space supports only 32-bit accesses. However, standard UEFI and Linux
-drivers may perform 8-bit and 16-bit read/write to this space which will end up in erroneous result.
-To avoid this, software workarounds has been added to convert the 8-bit/16-bit access to 32-bit access
-using read-modify-write method.
-
-
---------------
-
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
-
diff --git a/docs/n1sdp/release-notes.rst b/docs/n1sdp/release-notes.rst
deleted file mode 100755
index 9bf08b0..0000000
--- a/docs/n1sdp/release-notes.rst
+++ /dev/null
@@ -1,70 +0,0 @@
-Release Notes
-=============
-
-.. section-numbering::
-    :suffix: .
-
-.. contents::
-
-
-Features and Fixes
-------------------
-The following is a summary of the key software features of the tagged N1SDP-2020.12.15 release.
-
-- Yocto based BSP build to generate Poky distribution image and board firmware binary package.
-- Restructuring the ubuntu build and packaging scripts to generate the custom ubuntu image.
-- Support for both single and multi-chip configurations.
-- Migrate to scp-v2.7 to fix the system shutdown on reaching temperature threshold.
-
-This release is made to restructure the N1SDP profile majorly considering the single and multi-chip profiles, for CCIX accelerator profile please refer to `N1SDP community portal`_.
-
-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 or limitations
----------------------------
-- If either of the two boards needs to boot-up in a single chip mode with a C2C setup,
-  then the other board should be powered off.
-- To boot a standard distribution on N1SDP platform the kernel must be patched
-  with the PCIe quirks. See the article `PCIE`_
-- PCIe root port is limited to GEN3 speed due to the on-board PCIe switch supporting maximum GEN3 speed.
-- Page Request Interface (PRI) feature is not available in both SMMUs interfaced with PCIe root ports.
-- Currently only Micron 8GB single Rank DIMM (part number: MTA9ASF1G72PZ-2G6D1) and
-  16GB dual Rank DIMMs (part number:MTA18ASF2G72PDZ-2G6E1) are supported.
-- Stability issues have been observed on long stress tests of the system.
-- On-board HDMI connection is not supported for graphics output. PCIe graphics card can be used for graphics support.
-
-Disclaimer
-------------
-- Limited Testing for now due to current global scenario, to be revisited once we get back on site.
-
-Support
--------
-For support email: support-subsystem-enterprise@arm.com
-
---------------
-
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
-
-
-.. _PCIE: pcie-support.rsti
-.. _N1SDP community portal: https://community.arm.com/developer/tools-software/oss-platforms/w/docs/458/neoverse-n1-sdp
-.. _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
diff --git a/docs/n1sdp/user-guide.rst b/docs/n1sdp/user-guide.rst
index 7245727..a8581d0 100644
--- a/docs/n1sdp/user-guide.rst
+++ b/docs/n1sdp/user-guide.rst
@@ -1,521 +1,2 @@
-User Guide
-==========
-
-.. 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-core 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 libncurses-dev libz-dev python-pip
-
-**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 its recommended to install repo using the ``curl`` method.
-
-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-2020.12.15
-
-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 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-linaro-arm
-    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-linaro-arm}"
-    # 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-linaro-arm
-    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.4 for N1SDP`_.
-
-+--------+-------------------------------------------------------------------------------------------------+
-| Recipe | <n1sdp_workspace>/bsp/layers/meta-arm/meta-arm-bsp/recipes-kernel/linux/linux-linaro-arm_5.4.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 | <tc0_workspace>/bsp/layers/openembedded-core/meta/recipes-core/images/core-image-base.bb          |
-+--------+---------------------------------------------------------------------------------------------------+
-| Files  | * <tc0_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
-
-
-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.
-
-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
-        git clone http://git.linaro.org/landing-teams/working/arm/n1sdp-pcie-quirk.git
-        cd kernel-release/
-        git am ../n1sdp-pcie-quirk/linux/\*.patch
-        mkdir out
-        cp -v /boot/config-5.4.0+  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.4.0 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.4 for N1SDP: https://git.linaro.org/landing-teams/working/arm/kernel-release.git
-.. _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, Arm Limited. All rights reserved.*
+The N1Sdp documentation has been migrated to
+https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-docs/-/tree/master/docs/n1sdp