From 0e4b90ea55ad37fe31c7569ac76b7351f801ccd3 Mon Sep 17 00:00:00 2001 From: Khasim Syed Mohammed Date: Fri, 22 Oct 2021 12:46:20 +0530 Subject: docs/n1sdp: remove n1sdp platform documentation 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 Change-Id: If182b1908c23fe515eed55764d73befdac85a303 --- docs/n1sdp/Errata-1315703.rst | 29 -- ...N1 system development platform EULA_windows.txt | 272 ----------- docs/n1sdp/Prepare_distro_image_for_N1SDP.rst | 227 --------- docs/n1sdp/cmn-performance-analysis.rst | 363 -------------- docs/n1sdp/coresight.rst | 160 ------- docs/n1sdp/multichip.rst | 117 ----- docs/n1sdp/pcie-sr-iov.rst | 53 --- docs/n1sdp/pcie-support.rst | 70 --- docs/n1sdp/release-notes.rst | 70 --- docs/n1sdp/user-guide.rst | 523 +-------------------- 10 files changed, 2 insertions(+), 1882 deletions(-) delete mode 100755 docs/n1sdp/Errata-1315703.rst delete mode 100755 docs/n1sdp/LES-PRE-21570v1.0 Neoverse N1 system development platform EULA_windows.txt delete mode 100755 docs/n1sdp/Prepare_distro_image_for_N1SDP.rst delete mode 100644 docs/n1sdp/cmn-performance-analysis.rst delete mode 100755 docs/n1sdp/coresight.rst delete mode 100755 docs/n1sdp/multichip.rst delete mode 100755 docs/n1sdp/pcie-sr-iov.rst delete mode 100644 docs/n1sdp/pcie-support.rst delete mode 100755 docs/n1sdp/release-notes.rst 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 . - 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 </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 </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 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 - - int main() - { - printf("N1SDP\n"); - - return 0; - } - -2. Disassemble the binary: - - *aarch64-linux-gnu-objdump test.out* - -.. code-block:: - - 0000000000400580
: - 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 - 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 -```` in these instructions: - -:: - - mkdir - cd - 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 `` 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 /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 -``/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 -``/ubuntu/build-scripts``. - -:: - - cd /ubuntu - ./build-scripts/build-ubuntu.sh - - Options that can be passed to script are: - [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 ``/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 /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 - # 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 - -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 | /bsp/layers/meta-arm/meta-arm-bsp/recipes-bsp/trusted-firmware-a/trusted-firmware-a-n1sdp.inc | -+--------+----------------------------------------------------------------------------------------------------------------+ -| Files | * /bsp/build-poky/tmp-poky/deploy/images/n1sdp/bl31-n1sdp.bin | -+--------+----------------------------------------------------------------------------------------------------------------+ - - -System Control Processor (SCP) -****************************** - -Based on `SCP Firmware`_. - -+--------+----------------------------------------------------------------------------------------------------+ -| Recipe | /bsp/layers/meta-arm/meta-arm-bsp/recipes-bsp/scp-firmware/scp-firmware-n1sdp.inc | -+--------+----------------------------------------------------------------------------------------------------+ -| Files | * /bsp/build-poky/tmp-poky/deploy/images/n1sdp/scp_ramfw.bin | -| | * /bsp/build-poky/tmp-poky/deploy/images/n1sdp/scp_romfw.bin | -| | * /bsp/build-poky/tmp-poky/deploy/images/n1sdp/mcp_ramfw.bin | -| | * /bsp/build-poky/tmp-poky/deploy/images/n1sdp/mcp_romfw.bin | -+--------+----------------------------------------------------------------------------------------------------+ - - -uefi edk2 -********* - -Based on `UEFI edk2`_. - -+--------+---------------------------------------------------------------------------------------------+ -| Recipe | /bsp/layers/meta-arm/meta-arm-bsp/recipes-bsp/uefi/edk2-firmware-n1sdp.inc | -+--------+---------------------------------------------------------------------------------------------+ -| Files | * /bsp/build-poky/tmp-poky/deploy/images/n1sdp/uefi.bin | -+--------+---------------------------------------------------------------------------------------------+ - - -Linux -***** - -Based on `Linux 5.4 for N1SDP`_. - -+--------+-------------------------------------------------------------------------------------------------+ -| Recipe | /bsp/layers/meta-arm/meta-arm-bsp/recipes-kernel/linux/linux-linaro-arm_5.4.bb | -+--------+-------------------------------------------------------------------------------------------------+ -| Files | * /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 | /bsp/layers/openembedded-core/meta/recipes-core/images/core-image-base.bb | -+--------+---------------------------------------------------------------------------------------------------+ -| Files | * /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 - Motherboard Configuration Controller (MCC) - COM - Application Processor (AP) - COM - System Control Processor (SCP) - COM - Manageability Control Processor (MCP) - -Please check Device Manager in Windows or ``ls /dev/ttyUSB*`` in Linux to identify . - -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 ```` -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 -````. - -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 -````. - -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 -````. - -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 - -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 -- cgit v1.2.3