DOCSLIB.ORG

Porting Linux to a New Architecture, Done Right

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Porting Linux to a New Architecture, Done Right IBM Linux Technology Center Porting Linux to a new architecture, done right Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Overview 1 Status of new architecture ports 2 Typical approaches to new architectures 3 Lessons Learned 2 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right About me s390 architecture 2002-2005 PowerPC/Cell architecture 2005-now 32/64 bit syscall emulation Maintaining include/asm-generic Reviewing new architectures Learning about ARM 3 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Recently merged architectures 100000000 10000000 1000000 100000 arm xtensa avr32 blackfin mn10300 microblaze s*core tile 2.6.13 2.6.19 2.6.22 2.6.28 2.6.30 2.6.32 2.6.36 4 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Upcoming architectures nios II lm32 UniCore OpenRISC c64x MMIX nameless 48-bit architecture nameless DSP architecture 5 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right What makes architecture ports so hard? Typical approaches to new architectures 6 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Language barrier #1: English Homes of the current architecture maintainers 7 / 27 Arnd Bergmann c 2010 IBM Corporation pragmatically object-oriented freestanding ILP32/LP64 GNU 99 with static annotations and enforced coding style Porting Linux to a new architecture, done right Language barrier #2: C C 8 / 27 Arnd Bergmann c 2010 IBM Corporation pragmatically object-oriented freestanding ILP32/LP64 with static annotations and enforced coding style Porting Linux to a new architecture, done right Language barrier #2: C GNU C99 8 / 27 Arnd Bergmann c 2010 IBM Corporation pragmatically object-oriented freestanding ILP32/LP64 and enforced coding style Porting Linux to a new architecture, done right Language barrier #2: C GNU C99 with static annotations 8 / 27 Arnd Bergmann c 2010 IBM Corporation pragmatically object-oriented freestanding and enforced coding style Porting Linux to a new architecture, done right Language barrier #2: C ILP32/LP64 GNU C99 with static annotations 8 / 27 Arnd Bergmann c 2010 IBM Corporation pragmatically object-oriented and enforced coding style Porting Linux to a new architecture, done right Language barrier #2: C freestanding ILP32/LP64 GNU C99 with static annotations 8 / 27 Arnd Bergmann c 2010 IBM Corporation pragmatically and enforced coding style Porting Linux to a new architecture, done right Language barrier #2: C object-oriented freestanding ILP32/LP64 GNU C99 with static annotations 8 / 27 Arnd Bergmann c 2010 IBM Corporation and enforced coding style Porting Linux to a new architecture, done right Language barrier #2: C pragmatically object-oriented freestanding ILP32/LP64 GNU C99 with static annotations 8 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Language barrier #2: C pragmatically object-oriented freestanding ILP32/LP64 GNU C99 with static annotations and enforced coding style 8 / 27 Arnd Bergmann c 2010 IBM Corporation Noncoherent I/O Out-of-order I/O Memory management units Multiple ABIs Multiple ISAs Multiple platforms Timekeeping Porting Linux to a new architecture, done right Architectural challenges Symmetric Multiprocessing 9 / 27 Arnd Bergmann c 2010 IBM Corporation Out-of-order I/O Memory management units Multiple ABIs Multiple ISAs Multiple platforms Timekeeping Porting Linux to a new architecture, done right Architectural challenges Symmetric Multiprocessing Noncoherent I/O 9 / 27 Arnd Bergmann c 2010 IBM Corporation Memory management units Multiple ABIs Multiple ISAs Multiple platforms Timekeeping Porting Linux to a new architecture, done right Architectural challenges Symmetric Multiprocessing Noncoherent I/O Out-of-order I/O 9 / 27 Arnd Bergmann c 2010 IBM Corporation Multiple ABIs Multiple ISAs Multiple platforms Timekeeping Porting Linux to a new architecture, done right Architectural challenges Symmetric Multiprocessing Noncoherent I/O Out-of-order I/O Memory management units 9 / 27 Arnd Bergmann c 2010 IBM Corporation Multiple ISAs Multiple platforms Timekeeping Porting Linux to a new architecture, done right Architectural challenges Symmetric Multiprocessing Noncoherent I/O Out-of-order I/O Memory management units Multiple ABIs 9 / 27 Arnd Bergmann c 2010 IBM Corporation Multiple platforms Timekeeping Porting Linux to a new architecture, done right Architectural challenges Symmetric Multiprocessing Noncoherent I/O Out-of-order I/O Memory management units Multiple ABIs Multiple ISAs 9 / 27 Arnd Bergmann c 2010 IBM Corporation Timekeeping Porting Linux to a new architecture, done right Architectural challenges Symmetric Multiprocessing Noncoherent I/O Out-of-order I/O Memory management units Multiple ABIs Multiple ISAs Multiple platforms 9 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Architectural challenges Symmetric Multiprocessing Noncoherent I/O Out-of-order I/O Memory management units Multiple ABIs Multiple ISAs Multiple platforms Timekeeping 9 / 27 Arnd Bergmann c 2010 IBM Corporation Copy from ARM Copy from Tile Do not copy at all! Porting Linux to a new architecture, done right Where to start Copy from x86 10 / 27 Arnd Bergmann c 2010 IBM Corporation Copy from x86 Copy from Tile Do not copy at all! Porting Linux to a new architecture, done right Where to start Copy from ARM 10 / 27 Arnd Bergmann c 2010 IBM Corporation Copy from x86 Copy from ARM Do not copy at all! Porting Linux to a new architecture, done right Where to start Copy from Tile 10 / 27 Arnd Bergmann c 2010 IBM Corporation Copy from x86 Copy from ARM Copy from Tile Porting Linux to a new architecture, done right Where to start Do not copy at all! 10 / 27 Arnd Bergmann c 2010 IBM Corporation One minimal syscall list! Cover all the simple implementations Porting Linux to a new architecture, done right Generic header files 42 versions of struct stat? 11 / 27 Arnd Bergmann c 2010 IBM Corporation Cover all the simple implementations Porting Linux to a new architecture, done right Generic header files 42 versions of struct stat? One minimal syscall list! 11 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Generic header files 42 versions of struct stat? One minimal syscall list! Cover all the simple implementations 11 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Generic Architecture template Early Boot code zImage compression Library functions device tree Trap handling Signal handling ptrace pci 12 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right User space: runtime glibc/eglibc uClibc klibc 13 / 27 Arnd Bergmann c 2010 IBM Corporation Embedded distribution buildroot yocto emdebian Busybox initramfs Porting Linux to a new architecture, done right User space: distro Full distribution Debian, Fedora, OpenSUSE, Ubuntu, Gentoo, ... 14 / 27 Arnd Bergmann c 2010 IBM Corporation Busybox initramfs Porting Linux to a new architecture, done right User space: distro Full distribution Debian, Fedora, OpenSUSE, Ubuntu, Gentoo, ... Embedded distribution buildroot yocto emdebian 14 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right User space: distro Full distribution Debian, Fedora, OpenSUSE, Ubuntu, Gentoo, ... Embedded distribution buildroot yocto emdebian Busybox initramfs 14 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Lessons Learned 15 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Lesson #1 Start small 16 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Lesson #2 Generalize existing code for your special case 17 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Lesson #3 Understand the development process 18 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Lesson #4 Follow the upstream kernel 19 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Lesson #5 Debug your system with qemu with gdb 20 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Lesson #6 Simplify drivers using virtio and hvc 21 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Lesson #7 Describe SoC in a flattened device tree 22 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Lesson #8 Clean up after sparse and checkpatch 23 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Lesson #9 Run lockdep enabled kernels 24 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Lesson #10 Become a git master 25 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Legal Statement This work represents the view of the author and does not necessarily represent the view of IBM. IBM, IBM (logo), e-business (logo), pSeries, e (logo) server, and xSeries are trademarks or registered trademarks of International Business Machines Corporation in the United States and/or other countries. Linux is a registered trademark of Linus Torvalds. Other company, product, and service names may be trademarks or service marks of others. 26 / 27 Arnd Bergmann c 2010 IBM Corporation Porting Linux to a new architecture, done right Questions? 27 / 27 Arnd Bergmann c 2010 IBM Corporation.
Load more

Recommended publications
  • FUJITSU AI Zinrai Deep Learning System 200M/210H Software License Terms
    FUJITSU AI Zinrai Deep Learning System 200M/210H Software License Terms Copyright 2021 FUJITSU LIMITED P3KD-1962-01EN 1. NVIDIA Product License Terms This product uses the following NVIDIA products. Name Version Tesla Driver for Linux x64 460.73.01 cuDNN 8.2.2 These NVIDIA products can be downloaded from the NVIDIA home page. http://www.nvidia.com/page/home.html Regarding the terms and conditions of the license for Tesla Driver for Linux x64 460.73.01, see "END USER LICENSE AGREEMENTS (EULA)" in the Appendix. Regarding the terms and conditions of the license for cuDNN 8.2.2, see "NVIDIA SOFTWARE LICENSE AGREEMENT" in the Appendix. 2. NGC Software This product contains the open source software ("OSS") as described in this document. The license terms for each OSS are as described below. • PyTorch 1.9.0 From PyTorch: Copyright (c) 2016- Facebook, Inc (Adam Paszke) Copyright (c) 2014- Facebook, Inc (Soumith Chintala) Copyright (c) 2011-2014 Idiap Research Institute (Ronan Collobert) Copyright (c) 2012-2014 Deepmind Technologies (Koray Kavukcuoglu) Copyright (c) 2011-2012 NEC Laboratories America (Koray Kavukcuoglu) Copyright (c) 2011-2013 NYU (Clement Farabet) Copyright (c) 2006-2010 NEC Laboratories America (Ronan Collobert, Leon Bottou, Iain Melvin, Jason Weston) Copyright (c) 2006 Idiap Research Institute (Samy Bengio) Copyright (c) 2001-2004 Idiap Research Institute (Ronan Collobert, Samy Bengio, Johnny Mariethoz) From Caffe2: Copyright (c) 2016-present, Facebook Inc. All rights reserved. All contributions by Facebook: Copyright (c) 2016 Facebook Inc. All contributions by Google: Copyright (c) 2015 Google Inc. All rights reserved. All contributions by Yangqing Jia: Copyright (c) 2015 Yangqing Jia All rights reserved.
    [Show full text]
  • Also Includes Slides and Contents From
    The Compilation Toolchain Cross-Compilation for Embedded Systems Prof. Andrea Marongiu ([email protected]) Toolchain The toolchain is a set of development tools used in association with source code or binaries generated from the source code • Enables development in a programming language (e.g., C/C++) • It is used for a lot of operations such as a) Compilation b) Preparing Libraries Most common toolchain is the c) Reading a binary file (or part of it) GNU toolchain which is part of d) Debugging the GNU project • Normally it contains a) Compiler : Generate object files from source code files b) Linker: Link object files together to build a binary file c) Library Archiver: To group a set of object files into a library file d) Debugger: To debug the binary file while running e) And other tools The GNU Toolchain GNU (GNU’s Not Unix) The GNU toolchain has played a vital role in the development of the Linux kernel, BSD, and software for embedded systems. The GNU project produced a set of programming tools. Parts of the toolchain we will use are: -gcc: (GNU Compiler Collection): suite of compilers for many programming languages -binutils: Suite of tools including linker (ld), assembler (gas) -gdb: Code debugging tool -libc: Subset of standard C library (assuming a C compiler). -bash: free Unix shell (Bourne-again shell). Default shell on GNU/Linux systems and Mac OSX. Also ported to Microsoft Windows. -make: automation tool for compilation and build Program development tools The process of converting source code to an executable binary image requires several steps, each with its own tool.
    [Show full text]
  • FPGA BASED RECONFIGURABLE BODY AREA NETWORK USING Nios II and Uclinux
    FPGA BASED RECONFIGURABLE BODY AREA NETWORK USING Nios II AND uClinux A Thesis Submitted to the College of Graduate Studies and Research in Partial Fulfillment of the Requirements for the Degree of Master of Science in the Department of Electrical and Computer Engineering University of Saskatchewan by Anthony Voykin Saskatoon, Saskatchewan, Canada c Copyright Anthony Voykin, April 2013. All rights reserved. Permission to Use In presenting this thesis in partial fulfillment of the requirements for a Postgraduate degree from the University of Saskatchewan, it is agreed that the Libraries of this University may make it freely available for inspection. Permission for copying of this thesis in any manner, in whole or in part, for scholarly purposes may be granted by the professors who supervised this thesis work or, in their absence, by the Head of the Department of Electrical and Computer Engineering or the Dean of the College of Graduate Studies and Research at the University of Saskatchewan. Any copying, publication, or use of this thesis, or parts thereof, for financial gain without the written permission of the author is strictly prohibited. Proper recognition shall be given to the author and to the University of Saskatchewan in any scholarly use which may be made of any material in this thesis. Request for permission to copy or to make any other use of material in this thesis in whole or in part should be addressed to: Head of the Department of Electrical and Computer Engineering 57 Campus Drive University of Saskatchewan Saskatoon, Saskatchewan, Canada S7N 5A9 i Acknowledgments I would like to thank my advisors Professor Ron Bolton and Professor Francis Bui for providing me with guidance and support necessary to complete my thesis work.
    [Show full text]
  • Embedded Linux Systems with the Yocto Project™
    OPEN SOURCE SOFTWARE DEVELOPMENT SERIES Embedded Linux Systems with the Yocto Project" FREE SAMPLE CHAPTER SHARE WITH OTHERS �f, � � � � Embedded Linux Systems with the Yocto ProjectTM This page intentionally left blank Embedded Linux Systems with the Yocto ProjectTM Rudolf J. Streif Boston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sidney • Hong Kong • Seoul • Singapore • Taipei • Tokyo Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales depart- ment at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected]. Visit us on the Web: informit.com Cataloging-in-Publication Data is on file with the Library of Congress.
    [Show full text]
  • Embedded System Setting up Development Environment
    Embedded System Setting up Development Environment Tool chain installation GCC tool chain includes gcc compiler,assembler, linker, and other related utilities. (root@host)#rpm –ivh armtools-2.95.3- 5.i386.rpm Add /usr/local/gnu-2.95.3/bin to the searching path. (root@host)# export PATH=/usr/local/gnu- 2.95.3/bin:$PATH Setting up Development Environment Installing uClibc (root@host)#rpm –ivh uClibc-0.9.5- 1.i386.rpm The uClibc will be installed in /usr/local/uClibc-0.9.5 Building busybox BusyBox: The Swiss Army Knife of Embedded Linux Official site: http://busybox.net Install the BusyBox Configure the function of busybox Modify Makefile make Configure the function of busybox Config.h // This file defines the feature set to be compiled into busybox. // When you turn things off here, they won’t be compiled in at all. // //// This file is parsed by sed. You MUST use single line comments. // i.e., //#define BB_BLAH // // BusyBox Applications //#define BB_ADJTIMEX //#define BB_AR #define BB_ASH … # If you are running a cross compiler, you may want to set this # to something more interesting, like “powerpc-linux-“. CROSS = arm-elf- CC = $(CROSS)gcc … CROSS_CFLAGS+= -nostdinc –I$(LIBCDIR)/include –I$(GCCINCDIR) #Add below LIBCDIR=/usr/local/uClibc-0.9.5/linux-2.0.x GCCINCDIR=/usr/local/gnu-2.95.3/lib/gcc-lib/arm-elf/2.95/include Modify Makefile # If you are running a cross compiler, you may want to set this # to something more interesting, like “powerpc-linux-“. CROSS = arm-elf- CC = $(CROSS)gcc … CROSS_CFLAGS+= -nostdinc –I$(LIBCDIR)/include
    [Show full text]
  • Operating Systems and Applications for Embedded Systems >>> Toolchains
    >>> Operating Systems And Applications For Embedded Systems >>> Toolchains Name: Mariusz Naumowicz Date: 31 sierpnia 2018 [~]$ _ [1/19] >>> Plan 1. Toolchain Toolchain Main component of GNU toolchain C library Finding a toolchain 2. crosstool-NG crosstool-NG Installing Anatomy of a toolchain Information about cross-compiler Configruation Most interesting features Sysroot Other tools POSIX functions AP [~]$ _ [2/19] >>> Toolchain A toolchain is the set of tools that compiles source code into executables that can run on your target device, and includes a compiler, a linker, and run-time libraries. [1. Toolchain]$ _ [3/19] >>> Main component of GNU toolchain * Binutils: A set of binary utilities including the assembler, and the linker, ld. It is available at http://www.gnu.org/software/binutils/. * GNU Compiler Collection (GCC): These are the compilers for C and other languages which, depending on the version of GCC, include C++, Objective-C, Objective-C++, Java, Fortran, Ada, and Go. They all use a common back-end which produces assembler code which is fed to the GNU assembler. It is available at http://gcc.gnu.org/. * C library: A standardized API based on the POSIX specification which is the principle interface to the operating system kernel from applications. There are several C libraries to consider, see the following section. [1. Toolchain]$ _ [4/19] >>> C library * glibc: Available at http://www.gnu.org/software/libc. It is the standard GNU C library. It is big and, until recently, not very configurable, but it is the most complete implementation of the POSIX API. * eglibc: Available at http://www.eglibc.org/home.
    [Show full text]
  • A Review on Elliptic Curve Cryptography for Embedded Systems
    International Journal of Computer Science & Information Technology (IJCSIT), Vol 3, No 3, June 2011 A REVIEW ON ELLIPTIC CURVE CRYPTOGRAPHY FOR EMBEDDED SYSTEMS Rahat Afreen 1 and S.C. Mehrotra 2 1Tom Patrick Institute of Computer & I.T, Dr. Rafiq Zakaria Campus, Rauza Bagh, Aurangabad. (Maharashtra) INDIA [email protected] 2Department of C.S. & I.T., Dr. B.A.M. University, Aurangabad. (Maharashtra) INDIA [email protected] ABSTRACT Importance of Elliptic Curves in Cryptography was independently proposed by Neal Koblitz and Victor Miller in 1985.Since then, Elliptic curve cryptography or ECC has evolved as a vast field for public key cryptography (PKC) systems. In PKC system, we use separate keys to encode and decode the data. Since one of the keys is distributed publicly in PKC systems, the strength of security depends on large key size. The mathematical problems of prime factorization and discrete logarithm are previously used in PKC systems. ECC has proved to provide same level of security with relatively small key sizes. The research in the field of ECC is mostly focused on its implementation on application specific systems. Such systems have restricted resources like storage, processing speed and domain specific CPU architecture. KEYWORDS Elliptic curve cryptography Public Key Cryptography, embedded systems, Elliptic Curve Digital Signature Algorithm ( ECDSA), Elliptic Curve Diffie Hellman Key Exchange (ECDH) 1. INTRODUCTION The changing global scenario shows an elegant merging of computing and communication in such a way that computers with wired communication are being rapidly replaced to smaller handheld embedded computers using wireless communication in almost every field. This has increased data privacy and security requirements.
    [Show full text]
  • Betrfs: a Right-Optimized Write-Optimized File System
    BetrFS: A Right-Optimized Write-Optimized File System William Jannen, Jun Yuan, Yang Zhan, Amogh Akshintala, Stony Brook University; John Esmet, Tokutek Inc.; Yizheng Jiao, Ankur Mittal, Prashant Pandey, and Phaneendra Reddy, Stony Brook University; Leif Walsh, Tokutek Inc.; Michael Bender, Stony Brook University; Martin Farach-Colton, Rutgers University; Rob Johnson, Stony Brook University; Bradley C. Kuszmaul, Massachusetts Institute of Technology; Donald E. Porter, Stony Brook University https://www.usenix.org/conference/fast15/technical-sessions/presentation/jannen This paper is included in the Proceedings of the 13th USENIX Conference on File and Storage Technologies (FAST ’15). February 16–19, 2015 • Santa Clara, CA, USA ISBN 978-1-931971-201 Open access to the Proceedings of the 13th USENIX Conference on File and Storage Technologies is sponsored by USENIX BetrFS: A Right-Optimized Write-Optimized File System William Jannen, Jun Yuan, Yang Zhan, Amogh Akshintala, John Esmet∗, Yizheng Jiao, Ankur Mittal, Prashant Pandey, Phaneendra Reddy, Leif Walsh∗, Michael Bender, Martin Farach-Colton†, Rob Johnson, Bradley C. Kuszmaul‡, and Donald E. Porter Stony Brook University, ∗Tokutek Inc., †Rutgers University, and ‡Massachusetts Institute of Technology Abstract (microwrites). Examples include email delivery, creat- The Bε -tree File System, or BetrFS, (pronounced ing lock files for an editing application, making small “better eff ess”) is the first in-kernel file system to use a updates to a large file, or updating a file’s atime. The un- write-optimized index. Write optimized indexes (WOIs) derlying problem is that many standard data structures in are promising building blocks for storage systems be- the file-system designer’s toolbox optimize for one case cause of their potential to implement both microwrites at the expense of another.
    [Show full text]
  • Porting Musl to the M3 Microkernel TU Dresden
    Porting Musl to the M3 microkernel TU Dresden Sherif Abdalazim, Nils Asmussen May 8, 2018 Contents 1 Abstract 2 2 Introduction 3 2.1 Background.............................. 3 2.2 M3................................... 4 3 Picking a C library 5 3.1 C libraries design factors . 5 3.2 Alternative C libraries . 5 4 Porting Musl 7 4.1 M3andMuslbuildsystems ..................... 7 4.1.1 Scons ............................. 7 4.1.2 GNUAutotools........................ 7 4.1.3 Integrating Autotools with Scons . 8 4.2 Repositoryconfiguration. 8 4.3 Compilation.............................. 8 4.4 Testing ................................ 9 4.4.1 Syscalls ............................ 9 5 Evaluation 10 5.1 PortingBusyboxcoreutils . 10 6 Conclusion 12 1 Chapter 1 Abstract Today’s processing workloads require the usage of heterogeneous multiproces- sors to utilize the benefits of specialized processors and accelerators. This has, in turn, motivated new Operating System (OS) designs to manage these het- erogeneous processors and accelerators systematically. M3 [9] is an OS following the microkernel approach. M3 uses a hardware/- software co-design to exploit the heterogeneous systems in a seamless and effi- cient form. It achieves that by abstracting the heterogeneity of the cores via a Data Transfer Unit (DTU). The DTU abstracts the heterogeneity of the cores and accelerators so that they can communicate systematically. I have been working to enhance the programming environment in M3 by porting a C library to M3. I have evaluated different C library implementations like the GNU C Library (glibc), Musl, and uClibc. I decided to port Musl as it has a relatively small code base with fewer configurations. It is simpler to port, and it started to gain more ground in embedded systems which are also a perfect match for M3 applications.
    [Show full text]
  • MC-1200 Series Linux Software User's Manual
    MC-1200 Series Linux Software User’s Manual Version 1.0, November 2020 www.moxa.com/product © 2020 Moxa Inc. All rights reserved. MC-1200 Series Linux Software User’s Manual The software described in this manual is furnished under a license agreement and may be used only in accordance with the terms of that agreement. Copyright Notice © 2020 Moxa Inc. All rights reserved. Trademarks The MOXA logo is a registered trademark of Moxa Inc. All other trademarks or registered marks in this manual belong to their respective manufacturers. Disclaimer Information in this document is subject to change without notice and does not represent a commitment on the part of Moxa. Moxa provides this document as is, without warranty of any kind, either expressed or implied, including, but not limited to, its particular purpose. Moxa reserves the right to make improvements and/or changes to this manual, or to the products and/or the programs described in this manual, at any time. Information provided in this manual is intended to be accurate and reliable. However, Moxa assumes no responsibility for its use, or for any infringements on the rights of third parties that may result from its use. This product might include unintentional technical or typographical errors. Changes are periodically made to the information herein to correct such errors, and these changes are incorporated into new editions of the publication. Technical Support Contact Information www.moxa.com/support Moxa Americas Moxa China (Shanghai office) Toll-free: 1-888-669-2872 Toll-free: 800-820-5036 Tel: +1-714-528-6777 Tel: +86-21-5258-9955 Fax: +1-714-528-6778 Fax: +86-21-5258-5505 Moxa Europe Moxa Asia-Pacific Tel: +49-89-3 70 03 99-0 Tel: +886-2-8919-1230 Fax: +49-89-3 70 03 99-99 Fax: +886-2-8919-1231 Moxa India Tel: +91-80-4172-9088 Fax: +91-80-4132-1045 Table of Contents 1.
    [Show full text]
  • Embedded Linux Training
    Free Electrons Embedded Linux training Gregory Clement Thomas Petazzoni Michael Opdenacker Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http//free-electrons.com Rights to copy © Copyright 2004-2011, Free Electrons [email protected] Electronic version of this document available on http://free-electrons.com/doc/training/embedded-linux Updates will be available on http://free-electrons.com/doc/training/embedded-linux/ Attribution ± ShareAlike 3.0 Corrections, suggestions, You are free contributions and translations are welcome! to copy, distribute, display, and perform the work to make derivative works Latest update: Feb 14, 2011 to make commercial use of the work Under the following conditions Attribution. You must give the original author credit. Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. License text: http://creativecommons.org/licenses/by-sa/3.0/legalcode Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http//free-electrons.com Linux kernel Linux device drivers Free Electrons Board support code Our services Mainstreaming kernel code Kernel debugging Custom Development System integration
    [Show full text]
  • MANAGING a REAL-TIME EMBEDDED LINUX PLATFORM with BUILDROOT John Diamond, Kevin Martin Fermi National Accelerator Laboratory, Batavia, IL 60510
    MANAGING A REAL-TIME EMBEDDED LINUX PLATFORM WITH BUILDROOT John Diamond, Kevin Martin Fermi National Accelerator Laboratory, Batavia, IL 60510 Desktop distributions are an awkward Buildroot + ucLibc + Busybox + RTAI Quantitative Results implementation of an Embedded RTOS Buildroot – downloads, unpacks, • Whole build process is automated resulting in • Architecture-dependent binary configures, compiles and installs system much quicker build times (hours not days) software automatically • Kernel and root filesystem size: 3.5 MB – 20 packages uClibc – Small-footprint standard C library MB (reduction of 99%) • Loaded with unnecessary software Busybox – all-in-one UNIX utilities and shell • Boot-time: ~9 seconds • Huge footprints RTAI – Real-Time Linux extensions = Qualitative Results • Allows integration with revision control into First Try: Build Linux from Source the platform development process, making it • Success! But.. 2. Buildroot’s menuconfig generates a package configuration file easier to manage an ecosystem of targets • Is as difficult as it sounds and kernel configuration file • Community support for x86 & ARM targets Linux Kernel • Overwhelming number of packages and Configuration gives us confidence that future targets can be patches Package supported without much effort 1. Developer Configuration • No version control configures build via Buildroot’s • Cross-compile even more headaches menuconfig Internet Build Process Power Supply Control Quench Protection Git / CVS / SVN and Regulation for the System for Tevatron Did not do what we needed: Fermilab Linac Electron Lens (TEL II) 3. The build process pulls 4. The output from the software packages from build process is a kernel • Small-footprint network bootable image the internet and custom bzImage bzImage file with an softare packages from a integrated root filesystem ARM Cortex A-9 source code repository file PC/104 AMD • Automated build system Geode SBC Beam Position Monitor Power Supply Control prototype for Fermilab and Regulation for • Support for multiple architectures 5.
    [Show full text]