DOCSLIB.ORG

A Reliable Booting System for Zynq Ultrascale+ Mpsoc Devices

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Reliable Booting System for Zynq Ultrascale+ Mpsoc Devices A reliable booting system for Zynq Ultrascale+ MPSoC devices An embedded solution that provides fallbacks in different parts of the Zynq MPSoC booting process, to assure successful booting into a Linux operating system. A thesis presented for the Bachelor of Science in Electrical Engineering at the University of Applied Sciences Utrecht Name Nekija Dˇzemaili Student ID 1702168 University supervisor Corn´eDuiser CERN supervisors Marc Dobson & Petr Zejdlˇ Field of study Electrical Engineering (embedded systems) CERN-THESIS-2021-031 17/03/2021 February 15th, 2021 Geneva, Switzerland A reliable booting system for Zynq Ultrascale+ MPSoC devices Disclaimer The board of the foundation HU University of Applied Sciences in Utrecht does not accept any form of liability for damage resulting from usage of data, resources, methods, or procedures as described in this report. Duplication without consent of the author or the college is not permitted. If the graduation assignment is executed within a company, explicit consent of the company is necessary for duplication or copying of text from this report. Het bestuur van de Stichting Hogeschool Utrecht te Utrecht aanvaardt geen enkele aansprakelijkheid voor schade voortvloeiende uit het gebruik van enig gegeven, hulpmiddel, werkwijze of procedure in dit verslag beschreven. Vermenigvuldiging zonder toestemming van de auteur(s) en de school is niet toegestaan. Indien het afstudeerwerk in een bedrijf is verricht, is voor vermenigvuldiging of overname van tekst uit dit verslag eveneens toestemming van het bedrijf vereist. N. Dˇzemaili page 1 of 110 A reliable booting system for Zynq Ultrascale+ MPSoC devices Preface This thesis was written for the BSc Electrical Engineering degree of the HU University of Applied Sciences Utrecht, the Netherlands. During the degree, I specialized in embedded systems and found myself in an environment that allowed me to excel as an engineer. I'd like to thank my professor Corn´eDuiser for being my mentor throughout the studies. Also for helping me through the thesis as my examiner and answering my many questions. Other professors, in particular Dr. Franc van der Bent, Hubert Schuit, and Bart Bozon are thanked for their interesting courses on embedded systems and fun company in the lab. The thesis was carried out over the period of 14 months at the CMS Data acquisition & trigger group of CERN. The CMS DAQ group granted me the opportunity to work on a challenging and interesting project involving the Zynq Ultrascale+ MPSoC. The thesis is written for engineers that want to learn about the Zynq Ultrascale+ MPSoC and its development. I'd like to thank Dr. Petr Zejdlˇ for mentoring me during the project. His guidance and kindness is tremendously appreciated. Not only did he support me during working hours, but also in his free time. His encouragement and faith motivated me to excel during the project. My countless amount of questions were all answered by Petr's expertise in the field of embedded systems. I'd like to thank Dr. Marc Dobson for being my supervisor and supporting me during my time at CERN. His positive criticism and keenness helped me many times during the thesis writing and SoC meetings. His expertise of the CMS-experiment and the data acquisition system helped me understand what I've been working for. Lastly, I'd like to thank Dominique Gigi, Dr. Emilio Meschi, Dr. Atilla Racz, and Dr. Frans Meijers, along with the rest of the CMS DAQ team, for their help and kindness during my time at CERN. They provided me with a friendly working environment in a time of global pandemics and uncertainty. Nekija Dˇzemaili Geneva, Switzerland 15th of February, 2021 N. Dˇzemaili page 2 of 110 A reliable booting system for Zynq Ultrascale+ MPSoC devices Abstract CERN is working on the High-Luminosity LHC upgrade which will be installed in 2025. As a result, the CMS-experiment and its data acquisition (DAQ) system will also be upgraded. The upgrade of the CMS DAQ system involves the installation of new electronics that will also host the Zynq Ultrascale+ MPSoC from Xilinx (Multiprocessor Systems on a Chip). The Zynq Ultrascale+ MPSoC will run control and monitoring software on a Linux operating system (OS). Booting a Linux OS on the Zynq MPSoC involves a complex multi-stage booting process. The complexity of the booting process introduces possible failures that can prevent the Zynq MPSoC from booting correctly. This thesis presents the research, design, implementation, and testing of a reliable booting system that recovers the Zynq MPSoC from boot failures, upgrade failures, and running failures. The reliable booting system consists of five fallbacks in different parts of the Zynq MPSoC booting process, to account for a wide range of failures. The fallbacks have been designed to bring the Zynq MPSoC to a well-known booted state after a failure. The booting system can also boot through the network and perform automatic firmware upgrades with a rollback on failure. Users of the hardware are automatically notified after a failure was detected and a fallback was triggered in the system. The booting system is automatically built and packaged by a continuous integration build system. It has been made portable for new hardware by integrating the system in an easy-to-use board support package. Research on the possible failures in the Zynq MPSoC has been carried out. The test results have concluded that the fallbacks are able to successfully recover the Zynq MPSoC from all the researched failures. The results also highlighted a few areas that can be researched in a follow-up project to further improve the reliable booting system. N. Dˇzemaili page 3 of 110 A reliable booting system for Zynq Ultrascale+ MPSoC devices Table of contents Introduction 8 1 The CERN laboratory 9 1.1 Introduction to CERN . .9 1.2 CERN's accelerator complex . .9 1.3 The CMS experiment . 10 1.3.1 CMS sub-detectors . 11 1.3.2 CMS DAQ system . 12 2 Project description 14 2.1 Background . 14 2.2 Objective . 15 2.3 Requirements & Preconditions . 15 2.4 Reliability requirement . 16 2.5 Final products . 16 3 Background research 17 3.1 Zynq MPSoC workings and internals . 17 3.1.1 Zynq MPSoC booting overview . 17 3.1.2 Zynq MPSoC hardware overview . 17 3.1.3 The Application Processing Unit (APU) . 18 3.1.4 I/O peripherals and interfaces . 19 3.1.5 The Platform Management Unit (PMU) . 20 3.1.6 The Configuration Security Unit (CSU) . 21 3.2 Zynq MPSoC booting process . 22 3.2.1 The PMU BootROM . 22 3.2.2 The CSU BootROM . 22 3.2.3 The first-stage bootloader (FSBL) . 24 3.2.4 The ARM trusted firmware (ATF) . 25 3.2.5 The second-stage bootloader (U-Boot) . 25 3.2.6 Kernel booting . 26 3.2.7 Booting process summary . 26 3.3 Zynq MPSoC watchdog timers . 27 3.3.1 Watchdog timer workings . 27 3.3.2 Watchdog timer heartbeat daemon in Linux . 28 3.4 The Linux crashkernel . 28 3.4.1 Crashkernel workings . 28 3.4.2 Early kdump support in CentOS 8 . 30 3.4.3 Crashkernel user notifications . 30 3.4.4 Crashkernel support for Zynq MPSoC . 30 4 Research and analysis 31 4.1 Failure requirements . 31 4.1.1 Booting failures . 31 4.1.2 Upgrade failures . 31 4.1.3 Running failures . 31 Table of contents N. Dˇzemaili page 4 of 110 A reliable booting system for Zynq Ultrascale+ MPSoC devices 4.2 Failure categorization . 31 4.2.1 Pre-boot failures . 31 4.2.2 FSBL failures . 32 4.2.3 U-Boot stage failures . 33 4.2.4 Linux kernel boot failures . 33 4.2.5 Other failures . 34 4.3 Follow-up on boot and upgrade failures . 35 4.3.1 Backup-boots, boot counting and firmware upgrades . 35 4.3.2 Existing boot counting feature in U-Boot . 36 4.4 Summary and discussion of failures and fallbacks . 36 4.4.1 Tradeoff between fallbacks . 37 4.4.2 SD-card backup boot device . 37 5 High-level design 38 5.1 Reliable booting system . 38 5.2 RELBOOT & RELUP mechanisms . 39 5.2.1 RELBOOT & RELUP script . 39 5.2.2 RELBOOT & RELUP Linux daemon . 40 6 Implementation 42 6.1 Golden image search mechanism . 42 6.1.1 Boot image preparation . 42 6.1.2 Enabling FSBL debug info . 42 6.2 RELBOOT & RELUP mechanisms . 43 6.2.1 Firmware structure on TFTP server . 43 6.2.2 RELBOOT & RELUP script low-level design . 44 6.2.3 Script integration in boot image . 46 6.2.4 RELBOOT & RELUP Linux daemon implementation . 46 6.3 Crashkernel mechanism . 48 6.3.1 Kernel configuration . 48 6.3.2 Memory reservation . 49 6.3.3 Device-tree modifications . 49 6.3.4 Enabling and starting kdump . 49 6.3.5 Crashkernel workarounds . 50 6.4 Watchdog timer . 52 6.4.1 PMU firmware configuration . 52 6.4.2 Kernel configuration . 52 6.4.3 Device-tree modifications . ..
Load more

Recommended publications
  • Security Analysis of Docker Containers in a Production Environment
    Security analysis of Docker containers in a production environment Jon-Anders Kabbe Master of Science in Communication Technology Submission date: June 2017 Supervisor: Colin Alexander Boyd, IIK Co-supervisor: Audun Bjørkøy, TIND Technologies Norwegian University of Science and Technology Department of Information Security and Communication Technology Title: Security Analysis of Docker Containers in a Production Environment Student: Jon-Anders Kabbe Problem description: Deployment of Docker containers has achieved its popularity by providing an au- tomatable and stable environment serving a particular application. Docker creates a separate image of a file system with everything the application require during runtime. Containers run atop the regular file system as separate units containing only libraries and tools that particular application require. Docker containers reduce the attack surface, improves process interaction and sim- plifies sandboxing. But containers also raise security concerns, reduced segregation between the operating system and application, out of date or variations in libraries and tools and is still an unsettled technology. Docker containers provide a stable and static environment for applications; this is achieved by creating a static image of only libraries and tools the specific application needs during runtime. Out of date tools and libraries are a major security risk when exposing applications over the Internet, but availability is essential in a competitive market. Does Docker raise some security concerns compared to standard application deploy- ment such as hypervisor-based virtual machines? Is the Docker “best practices” sufficient to secure the container and how does this compare to traditional virtual machine application deployment? Responsible professor: Colin Alexander Boyd, ITEM Supervisor: Audun Bjørkøy, TIND Technologies Abstract Container technology for hosting applications on the web is gaining traction as the preferred mode of deployment.
    [Show full text]
  • Adagio for the Internet of Things Iot Penetration Testing and Security Analysis of a Smart Plug
    DEGREE PROJECT IN COMPUTER ENGINEERING, FIRST CYCLE, 15 CREDITS STOCKHOLM, SWEDEN 2021 Adagio For The Internet Of Things IoT penetration testing and security analysis of a smart plug RAMAN SALIH KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Adagio For The Internet Of Things IoT penetration testing and security analysis of a smart plug Raman Salih Supervisor: Pontus Johnson Examiner: Robert Lagerström Abstract— The emergence of the Internet of Things (IoT) Index Terms— Hacking; Wi-Fi; Threat model; IoT security; shows us that more and more devices will be connected to Smart plug the internet for all types of different purposes. One of those devices, the smart plug, have been rapidly deployed because I. INTRODUCTION of the ease it brings users into achieving home automation by turning their previous dumb devices smart by giving them As technology becomes smaller, faster, and more the means of controlling the devices remotely. These IoT connected over time it leads to more and more potential devices that gives the user control could however pose devices to join the internet and exchange data between serious security problems if their vulnerabilities were not carefully investigated and analyzed before we blindly themselves. Everything from coffee makers to blinds for your integrate them into our everyday life. In this paper, we do a windows may one day be connected to the internet and be threat model and subsequent penetration testing on a smart controlled remotely and dynamically. This category of plug system made by particular brand by exploiting its devices is known as the Internet of Things (IoT) and is set to singular communication protocol and we successfully launch reach 20.4 billion connected devices by 2020 according to a five attacks: a replay attack, a MCU tampering attack, a forecast made by Gartner 1 .
    [Show full text]
  • A Letter to the FCC [PDF]
    Before the FEDERAL COMMUNICATIONS COMMISSION Washington, DC 20554 In the Matter of ) ) Amendment of Part 0, 1, 2, 15 and 18 of the ) ET Docket No. 15­170 Commission’s Rules regarding Authorization ) Of Radio frequency Equipment ) ) Request for the Allowance of Optional ) RM­11673 Electronic Labeling for Wireless Devices ) Summary The rules laid out in ET Docket No. 15­170 should not go into effect as written. They would cause more harm than good and risk a significant overreach of the Commission’s authority. Specifically, the rules would limit the ability to upgrade or replace firmware in commercial, off­the­shelf home or small­business routers. This would damage the compliance, security, reliability and functionality of home and business networks. It would also restrict innovation and research into new networking technologies. We present an alternate proposal that better meets the goals of the FCC, not only ensuring the desired operation of the RF portion of a Wi­Fi router within the mandated parameters, but also assisting in the FCC’s broader goals of increasing consumer choice, fostering competition, protecting infrastructure, and increasing resiliency to communication disruptions. If the Commission does not intend to prohibit the upgrade or replacement of firmware in Wi­Fi ​ ​ devices, the undersigned would welcome a clear statement of that intent. Introduction We recommend the FCC pursue an alternative path to ensuring Radio Frequency (RF) compliance from Wi­Fi equipment. We understand there are significant concerns regarding existing users of the Wi­Fi ​ spectrum, and a desire to avoid uncontrolled change. However, we most strenuously advise against prohibiting changes to firmware of devices containing radio components, and furthermore advise against allowing non­updatable devices into the field.
    [Show full text]
  • Home Automation for Tinkerers
    Home Automation for tinkerers Abílio Costa [email protected] Once upon a time... Where it all begun ● I had 3 wireless power sockets! (yay?) ● But I was using only one. Why? ○ Only a single remote: ■ How to use the other two in different rooms? ○ They were dumb. ¯\_(ツ)_/¯ ■ It would be nice to have one of them turn on/off on a schedule? Poor man’s solution ● An Arduino Nano + 433MHz RF transmitter + RF receiver. ○ Total cost: less than 5€. ○ Arduino sketch using the RC Switch library. ○ USB to a Raspberry Pi for the brains. ○ Script on the Raspberry Pi; exposing HTTP endpoints. ● My home was now so very smart! ○ Control each power socket through my phone. ○ Office desk power turns on automatically when I get home. ○ Bedroom lamp turned on automatically after the morning alarm. ○ I could buy more power sockets, even from other brands! ● The same idea can be used to interact with many other things: ○ Alarm sensors; Doorbells; Garage doors; etc. Next step: home automation software Why? ● Better management (my script wasn't going very far). ● Allow integrating other devices besides the power plugs. ● Make devices from different brands / protocols talk to each other. ● UI included! Home automation solutions ● Open-source software: ○ Home Assistant ○ Domoticz ○ OpenHAB ○ Pimatic ● Commercial hardware + software: ○ SmartThings ○ Vera ○ Xiaomi Home Assistant Home Assistant ● Good looking and customizable web UI (uses Google Polymer). ● Lightweight; extra functionality added with a plugin-like system. ● Very powerful automation engine (IFTTT on steroids). ● Autodiscovery: many devices will just show up without any config! ● Local: no cloud dependency! ● REST API available.
    [Show full text]
  • How to Install / Use Custom Firmware (Or CFW) on Any Sony
    www.markfixesstuff.co.uk Mark Fixes Stuff ‐ Sony PSP CFW guide V1.0 How to install / use Custom Firmware (or CFW) on any Sony PSP Scope: This document is intended to enable you to use Custom Firmware on you Playstation Portable console. It will work as a permanent install for PSP models in the 1000 and 2000 series, and will also function on later models as a loader that can be initiates at the start of each play session. Notes: ‐ I did not write this firmware! Credit for this goes to DJ Godman! ‐ This process is reversible, although as with any hack there is an unlikely chance you might brick your system. I cannot take responsibility for any issues you might encounter. ‐ I have use this process countless times with no problems. ‐ Although this process will allow the playing of pirated ISO files, I do not endorse nor condone piracy, and this process is described to allow you to use homebrew PSP games, emulators or your own ripped software that you own. Please read the entire document first and then you will be able to use it for reference as you hack your PSP! www.markfixesstuff.co.uk Mark Fixes Stuff ‐ Sony PSP CFW guide V1.0 Process: 1. Determine your current Official Firmware (OFW) Version. From the dashboard select Settings, then System Settings. Then System Information. You will see your PSP's official firmware version. Here it's 6.60. You will need at least 6.20!!! www.markfixesstuff.co.uk Mark Fixes Stuff ‐ Sony PSP CFW guide V1.0 2.
    [Show full text]
  • The Linux 2.4 Kernel's Startup Procedure
    The Linux 2.4 Kernel’s Startup Procedure William Gatliff 1. Overview This paper describes the Linux 2.4 kernel’s startup process, from the moment the kernel gets control of the host hardware until the kernel is ready to run user processes. Along the way, it covers the programming environment Linux expects at boot time, how peripherals are initialized, and how Linux knows what to do next. 2. The Big Picture Figure 1 is a function call diagram that describes the kernel’s startup procedure. As it shows, kernel initialization proceeds through a number of distinct phases, starting with basic hardware initialization and ending with the kernel’s launching of /bin/init and other user programs. The dashed line in the figure shows that init() is invoked as a kernel thread, not as a function call. Figure 1. The kernel’s startup procedure. Figure 2 is a flowchart that provides an even more generalized picture of the boot process, starting with the bootloader extracting and running the kernel image, and ending with running user programs. Figure 2. The kernel’s startup procedure, in less detail. The following sections describe each of these function calls, including examples taken from the Hitachi SH7750/Sega Dreamcast version of the kernel. 3. In The Beginning... The Linux boot process begins with the kernel’s _stext function, located in arch/<host>/kernel/head.S. This function is called _start in some versions. Interrupts are disabled at this point, and only minimal memory accesses may be possible depending on the capabilities of the host hardware.
    [Show full text]
  • Question Bank Mca Semester V Vol. I
    QUESTION BANK MCA SEMESTER V VOL. I 1 FOR PRIVATE CIRCULATION The Questions contained in this booklet have been prepared by the faculty of the Institute from the sources believed to be reliable. Neither the Institute nor the faculty gives any guarantee with respect to completeness or accuracy of the contents contained in the booklet and shall in no event be liable for any errors, omissions or damages arising out of use of the matter contained in the booklet. The Institute and the faculty specifically disclaim any implied warranty as to merchantability or fitness of the information for any particular purpose. 2 QUESTION BANK LINUX PROGRAMMING MCA 301 3 QUESTION BANK LINUX PROGRAMMING - MCA 301 MCA V UNIT - I I Test Your Skills: (a) State Whether the Following Statements are True or False: 1 The “no” option informs the machine that there is no grace period or time to wait for other users to log off. 2 Telnet command is used for changing the run level or state of the computer without rebooting. 3 IP address is a unique identifier for the system. 4 Transmission control protocol (TCP) builds on top of UPS and certifies that each message has been received. 5 Cron is known for arranging the files in the disk in chronological manner. 6 ARP (Address Resolution Protocol) converts IP address to MAC Address. 7 UNIX is a command-based system. 8 A program is synonymous with a process. 9 All UNIX flavors today offer a Command User Interface. 10 The operating system allocates memory for the program and loads the program to the allocated memory.
    [Show full text]
  • Firecracker: Lightweight Virtualization for Serverless Applications
    Firecracker: Lightweight Virtualization for Serverless Applications Alexandru Agache, Marc Brooker, Andreea Florescu, Alexandra Iordache, Anthony Liguori, Rolf Neugebauer, Phil Piwonka, and Diana-Maria Popa, Amazon Web Services https://www.usenix.org/conference/nsdi20/presentation/agache This paper is included in the Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’20) February 25–27, 2020 • Santa Clara, CA, USA 978-1-939133-13-7 Open access to the Proceedings of the 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’20) is sponsored by Firecracker: Lightweight Virtualization for Serverless Applications Alexandru Agache Marc Brooker Andreea Florescu Amazon Web Services Amazon Web Services Amazon Web Services Alexandra Iordache Anthony Liguori Rolf Neugebauer Amazon Web Services Amazon Web Services Amazon Web Services Phil Piwonka Diana-Maria Popa Amazon Web Services Amazon Web Services Abstract vantage over traditional server provisioning processes: mul- titenancy allows servers to be shared across a large num- Serverless containers and functions are widely used for de- ber of workloads, and the ability to provision new func- ploying and managing software in the cloud. Their popularity tions and containers in milliseconds allows capacity to be is due to reduced cost of operations, improved utilization of switched between workloads quickly as demand changes. hardware, and faster scaling than traditional deployment meth- Serverless is also attracting the attention of the research com- ods. The economics and scale of serverless applications de- munity [21,26,27,44,47], including work on scaling out video mand that workloads from multiple customers run on the same encoding [13], linear algebra [20, 53] and parallel compila- hardware with minimal overhead, while preserving strong se- tion [12].
    [Show full text]
  • Demystifying Internet of Things Security Successful Iot Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M
    Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security: Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Chandler, AZ, USA Chandler, AZ, USA Ned Smith David M. Wheeler Beaverton, OR, USA Gilbert, AZ, USA ISBN-13 (pbk): 978-1-4842-2895-1 ISBN-13 (electronic): 978-1-4842-2896-8 https://doi.org/10.1007/978-1-4842-2896-8 Copyright © 2020 by The Editor(s) (if applicable) and The Author(s) This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book’s Creative Commons license, unless indicated otherwise in a credit line to the material.
    [Show full text]
  • The Linux Startup Process
    The Linux startup process Jerry Feldman <[email protected]> The Linux Expertise Center Hewlett-Packard Company Document produced via OpenOffice.org Overview ● The Linux boot process – GRUB. This is the default for X86/Linux – LILO – Other boot loaders ● The Linux Operating modes – Single-user mode – Multi-user mode. ● Run Levels – What are run levels – What are the Linux standard run levels – How Linux manages run levels 2 The Linux Boot process ● The PC boot process is a 3-stage boot process that begins with the BIOS executing a short program that is stored in the Master Boot Record (MBR) of the first physical drive. Since this stage 1 boot loader needs to fit in the MBR, it is limited to 512 bytes and is normally written in assembly language. There are a number of boot loaders that can load Linux. ● GRUB and LILO are the most commonly used ones on X86 hardware. ® ® ● EFI is used on the Intel Itanium family. 3 The GRand Unified Bootloader The GRand Unified Bootloader (GRUB) is default boot loader on most distributions today. It has the capability to load a number of different operating systems. 1.The stage 1 boot resides in the MBR and contains the sector number of the stage 2 boot that is usually located in the /boot/grub directory on Linux. 2.The stage 2 boot loader presents a boot menu to the user based on /boot/grub/grub.conf or menu.lst. This contains a boot script. It is the stage2 loader actually loads the Linux kernel or 4 other OS.
    [Show full text]
  • Implementing Full Device Cloning on the NVIDIA Jetson Platform
    Implementing Full Device Cloning on the NVIDIA Jetson Platform March 2, 2018 Calvin Chen Linh Hoang Connor Smith Advisor: Professor Mark Claypool Sponsor - Mentor : NVIDIA - Jimmy Zhang Abstract NVIDIA’s Linux For Tegra development team provides support for many tools which exist on the Jetson-TX2 embedded AI computing device. While tools to clone the user partitions of the Jetson-TX2 exist, no tool exists to fully backup and restore all of the partitions and configurations of these boards. The goal of this project was to develop a tool that allows a user to create a complete clone of the Jetson-TX2 board’s partitions and their contents. We developed a series of bash scripts that fully backup the partitions and configurations of one Jetson-TX2 board and restore them onto another board of the same type. 1 Table of Contents Abstract 1 Table of Contents 2 1 Introduction 3 2 Background 5 2.1 Preliminary Research 5 2.1.1 UEFI Booting and Flashing 5 2.1.2 Tegra Linux Driver Package 8 2.1.3 Network File System 8 2.1.4 Jetson TX2 Bootloader 10 2.2 Linux Terminology, RCM boot and Initial ramdisk 12 2.2.1 Linux Terminology 12 2.2.2 USB Recovery Mode (RCM) Boot 13 2.2.3 Initial Ramdisk 14 2.3 Associated Technologies 15 2.3.1 Linux tools 15 2.3.2 Serial Console 16 3 Methodology 17 4 Product 20 4.1 Backup Script 20 4.2 Restore Script 22 4.3 Initial ramdisk (initrd) 24 4.4 Script Development Guidelines 26 4.4.1 Use Case 26 4.4.2 Integrity 26 4.4.3 Performance 27 5 Future Work 29 6 Conclusions 30 7 Bibliography 31 2 1 Introduction The Jetson-TX2 is a low power, high performance embedded artificial intelligence supercomputer utilized in many modern technologies.
    [Show full text]
  • Effective Cache Apportioning for Performance Isolation Under
    Effective Cache Apportioning for Performance Isolation Under Compiler Guidance Bodhisatwa Chatterjee Sharjeel Khan Georgia Institute of Technology Georgia Institute of Technology Atlanta, USA Atlanta, USA [email protected] [email protected] Santosh Pande Georgia Institute of Technology Atlanta, USA [email protected] Abstract cache partitioning to divide the LLC among the co-executing With a growing number of cores per socket in modern data- applications in the system. Ideally, a cache partitioning centers where multi-tenancy of a diverse set of applications scheme obtains overall gains in system performance by pro- must be efficiently supported, effective sharing of the last viding a dedicated region of cache memory to high-priority level cache is a very important problem. This is challenging cache-intensive applications and ensures security against because modern workloads exhibit dynamic phase behaviour cache-sharing attacks by the notion of isolated execution in - their cache requirements & sensitivity vary across different an otherwise shared LLC. Apart from achieving superior execution points. To tackle this problem, we propose Com- application performance and improving system throughput CAS, a compiler guided cache apportioning system that pro- [7, 20, 31], cache partitioning can also serve a variety of pur- vides smart cache allocation to co-executing applications in a poses - improving system power and energy consumption system. The front-end of Com-CAS is primarily a compiler- [6, 23], ensuring fairness in resource allocation [26, 36] and framework equipped with learning mechanisms to predict even enabling worst case execution-time analysis of real-time cache requirements, while the backend consists of allocation systems [18].
    [Show full text]