DOCSLIB.ORG

Machine Emulation with QEMU and Cross-Compilation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Instituto Superior de Engenharia do Porto Mestrado em Engenharia Eletrotécnica e de Computadores Arquitetura de Computadores Machine emulation with QEMU and cross-compilation Introduction This lesson addresses the execution of Linux systems on software emulated machines using the QEMU software. Two different machines will be considered, one with a x86-64 processor and another with 32 bit ARM processor. More specifically, in the case of the ARM machine, the emulate processor is the ARM1176, the same processor core used, for instance, in the original Raspberry Pi board. A Linux system is composed by the kernel - a file, with a few megabytes , containing the basic operating system services - and at least a file system, the root file system. This file system should contain the essential directories (e.g., /dev), and required utilities (mount, ip) and software (e.g., web server). Typically, the kernel file (also known as kernel image) is stored in a different partition, the boot partition. Additionally, there is usually software that must be installed in specific places of the storage device, in order to support the initial phase of the system start-up (booting). This software is usually denominated boot loader (e.g., GNU GRUB). Finally, the system image is a file that contains the exact contents of the target storage device, including the boot loader, the boot partition and partition containing the root file system. QEMU is a software for machine emulation, supporting several types of computers with processors from both architectures. The supported machines for the x86-64 can be queried using qemu-system-x86_64 -M ? while qemu-system-arm -M ? can be used to obtain the list of supported machines with A32 bit ARM processors. For a given machine, it is also possible to see the list of supported processors. For instance, to see the list of supported processors for the x86_64 default machine, type: qemu-system-x86_64 -cpu ? Both programs (qemu-system-arm and qemu-system-x86_64) share some features and common command line parameters. Of special interest is the capacity of acting as a boot loader for Linux systems. By using, the -kernel parameter, it is possible to specify the file containing the kernel of the Linux system to be used in the emulated machine. Therefore, it is not necessary to install a boot loader nor to include the Linux kernel in the system image. Machine emulation with QEMU and cross-compilation 1/7 ARCOM – MEEC – ISEP – 2020/2021 Exercises Create a new directory (e.g., lab2) to store all the files and directories mentioned in the following exercises. As a good practice, since the computers can be used by several students, this directory should be under a directory named upon you student number or name. i.e.: mkdir -p ~/student_number/lab2 cd ~/student_number/lab2 1- The x86_64 system Building the core commands and utilities We will start by creating a very simplistic root filesystem image, containing a shell and a small set of commands (cat, df, ls, uname, mount, free, ps). To obtain those commands, we will use the BusyBox utility. BusyBox provides, in the same executable, a wide variety of traditional commands for Unix-like systems. In what follows, we’ll configure and compile BusyBox to provide a shell and both the ls and uname commands. Check Busybox’s homepage, and download the source code of the latest stable version to your project directory (alternatively, you can use the version available at the web page). For instance: wget http://busybox.net/downloads/busybox-XXX.tar.bz2 Extract the archive files: tar xvf busybox-XXX.tar.bz2 Change the current directory to the created folder. Configure and compile BusyBox: make allnoconfig # Invoke setup menu (requires qt3-devel package) make xconfig #or, for text mode (requires ncurses-devel package): make menuconfig Choose the following options: • Under "Settings" (right side panel): • “Include busybox applet” • Below "Settings -> Build Options": • "Build BusyBox as a static binary" • Below "Settings -> Library Tuning" (but not immediately following): • “Command line editing” • Back to the left side panel, below "Applets": • Coreutils -> cat, df, ls, uname • Linux System utilities -> mount Machine emulation with QEMU and cross-compilation 2/7 ARCOM – MEEC – ISEP – 2020/2021 • Process utilities -> free, ps • Shells -> ash. Make sure that the “Use internal glob() imple- mentation” sub-option is selected. Save your configuration, exit the configuration screen and generate the executable1: make -j 2 #if you have a quad core CPU, use -j 4 At the end of the procedure, you should find the busybox file in the current directory. file busybox cd .. Creation of the root file system image In the initial working directory, type: dd if=/dev/zero of=rootfs-x86_64.img bs=4M count=1 The above command creates an empty file with a size of 4MiB. This file will be used as a virtual storage device. It will contain the root file system of our minimal Linux system. Create a directory to use as a mount point for the file system in rootfs-x86_64.img. mkdir m However, at this point, rootfs-x86_64.img is still blank. Next, we will create an empty EXT4 file system on rootfs-x86.img (using the mkfs.ext4 command), and we will mount it on m. These operations must be performed as root: mkfs.ext4 rootfs-x86_64.img su mount rootfs-x86_64.img m From this point on, every operation on m will be reflected to the file system in rootfs- x86_64.img. Let us start by creating some of the standard directories: cd m mkdir bin dev proc Finally, copy the busybox executable to the bin directory of the target file system and create the auxiliary symbolic links that provide access to the commands chosen during the configuration phase: 1 In case of error, make sure the glibc-static.i686 and glibc-devel.i686 packages are installed (dnf install) Machine emulation with QEMU and cross-compilation 3/7 ARCOM – MEEC – ISEP – 2020/2021 cp ../busybox-XXX/busybox bin/ #replace XXX with the correct suffix cd bin ln -s busybox cat ln -s busybox ps ln -s busybox df ln -s busybox free ln -s busybox ls ln -s busybox uname ln -s busybox mount ln -s busybox ash cd ../.. umount m #unmount rootfs-x86_64.img exit ls m After this sequence of commands, the m directory should be empty. That can be verified by the output of the ls m command. Emulation For simplicity, the Linux kernel will be the one used by the host machine. Therefore, to start the emulation of our minimal Linux system, type: qemu-system-x86_64 -kernel YYY \ -append "root=800 init=/bin/ash" \ -drive file=rootfs-x86_64.img,format=raw where YYY should be the absolute pathname of the kernel image used by your system (e.g., /boot/vmlinuz…). Check the /boot directory to find out the complete file name or just use the tab key to autocomplete. Write down the output of the following commands (the commands should be executed in the emulated machine). Note that you can use the shift+”page up” and shift+”page down” key combinations to scroll the screen output up and down. mount -t proc proc /proc cat /proc/cpuinfo #just the model name field free #just the first line df ps # just the processes not enclosed in [] # and just the PID and Command columns Machine emulation with QEMU and cross-compilation 4/7 ARCOM – MEEC – ISEP – 2020/2021 2 - The ARM system Building the core commands and utilities As for the x86_64 case, we will build a root file system based on the BusyBox utility. However, in this case, it is not possible to use the host compiler and linker to build the executable, since this Fedora distribution supports development just for x86 targets. In order to do that, a cross- compilation toolchain for the ARM processor will be required. Typically, a toolchain contains compiler(es), an assembler, a linker and the main libraries (e.g., the C library). It may also include additional development tools (e.g., debugger, code profiler). A cross-compilation toolchain allow us to build software to architectures other than the host architecture. There are publicly available pre-built cross-compilation toolchains for ARM processors (see, e.g., https://elinux.org/Toolchains). In the present case, we will use a prebuilt toolchain specially targeted for the Raspberry Pi system using the Buildroot software. Buildroot allows us to create a toolchain from the scratch, and, in the process, to choose the most suitable versions of the compiler and C library, among several other configuration parameters. This tool will be studied in more detail in future lessons. The toolchain is available in the lesson webpage. Download the toolchain file and extract its contents. Create a copy of the BusyBox build directory: cp -a busybox-xxx busybox-arm (where xxx is the busybox version in use) Cross-compile busybox: cd busybox-arm make clean make CROSS_COMPILE=ZZZ where ZZZ is the absolute pathname prefix to the toolchain utilities in your system (for instance, "/home/arcom1x/student_number/lab2/arm-buildroot-linux- uclibcgnueabihf_sdk-buildroot/bin/arm-linux-"). Check if the generated file has the correct architecture (ARM): file busybox Creation of the root file system image cp rootfs-x86_64.img rootfs-arm.img su mount rootfs-arm.img m cp busybox-arm/busybox m/bin/ umount m exit Machine emulation with QEMU and cross-compilation 5/7 ARCOM – MEEC – ISEP – 2020/2021 Emulation For this system, we will use the kernel-qemu-4.14.50-stretch kernel image and associated device tree blob/binary (DTB) file (obtained from https://github.com/dhruvvyas90/qemu-rpi-kernel). Both files are provided in the web page.
Recommended publications
  • Configuring UNIX-Specific Settings: Creating Symbolic Links : Snap

    Configuring UNIX-Specific Settings: Creating Symbolic Links : Snap

    Configuring UNIX-specific settings: Creating symbolic links Snap Creator Framework NetApp September 23, 2021 This PDF was generated from https://docs.netapp.com/us-en/snap-creator- framework/installation/task_creating_symbolic_links_for_domino_plug_in_on_linux_and_solaris_hosts.ht ml on September 23, 2021. Always check docs.netapp.com for the latest. Table of Contents Configuring UNIX-specific settings: Creating symbolic links . 1 Creating symbolic links for the Domino plug-in on Linux and Solaris hosts. 1 Creating symbolic links for the Domino plug-in on AIX hosts. 2 Configuring UNIX-specific settings: Creating symbolic links If you are going to install the Snap Creator Agent on a UNIX operating system (AIX, Linux, and Solaris), for the IBM Domino plug-in to work properly, three symbolic links (symlinks) must be created to link to Domino’s shared object files. Installation procedures vary slightly depending on the operating system. Refer to the appropriate procedure for your operating system. Domino does not support the HP-UX operating system. Creating symbolic links for the Domino plug-in on Linux and Solaris hosts You need to perform this procedure if you want to create symbolic links for the Domino plug-in on Linux and Solaris hosts. You should not copy and paste commands directly from this document; errors (such as incorrectly transferred characters caused by line breaks and hard returns) might result. Copy and paste the commands into a text editor, verify the commands, and then enter them in the CLI console. The paths provided in the following steps refer to the 32-bit systems; 64-bit systems must create simlinks to /usr/lib64 instead of /usr/lib.
  • CNTR: Lightweight OS Containers

    CNTR: Lightweight OS Containers

    CNTR: Lightweight OS Containers Jorg¨ Thalheim, Pramod Bhatotia Pedro Fonseca Baris Kasikci University of Edinburgh University of Washington University of Michigan Abstract fundamental to achieve high efficiency in virtualized datacenters and enables important use-cases, namely Container-based virtualization has become the de-facto just-in-time deployment of applications. Moreover, standard for deploying applications in data centers. containers significantly reduce operational costs through However, deployed containers frequently include a higher consolidation density and power minimization, wide-range of tools (e.g., debuggers) that are not required especially in multi-tenant environments. Because of all for applications in the common use-case, but they these advantages, it is no surprise that containers have seen are included for rare occasions such as in-production wide-spread adoption by industry, in many cases replacing debugging. As a consequence, containers are significantly altogether traditional virtualization solutions [17]. larger than necessary for the common case, thus increasing the build and deployment time. Despite being lightweight, deployed containers often include a wide-range of tools such as shells, editors, CNTR1 provides the performance benefits of lightweight coreutils, and package managers. These additional tools containers and the functionality of large containers by are usually not required for the application’s core function splitting the traditional container image into two parts: the — the common operational use-case — but they are “fat” image — containing the tools, and the “slim” image included for management, manual inspection, profiling, — containing the main application. At run-time, CNTR and debugging purposes [64]. In practice, this significantly allows the user to efficiently deploy the “slim” image and increases container size and, in turn, translates into then expand it with additional tools, when and if necessary, slower container deployment and inefficient datacenter by dynamically attaching the “fat” image.
  • Humidity Definitions

    Humidity Definitions

    ROTRONIC TECHNICAL NOTE Humidity Definitions 1 Relative humidity Table of Contents Relative humidity is the ratio of two pressures: %RH = 100 x p/ps where p is 1 Relative humidity the actual partial pressure of the water vapor present in the ambient and ps 2 Dew point / Frost the saturation pressure of water at the temperature of the ambient. point temperature Relative humidity sensors are usually calibrated at normal room temper - 3 Wet bulb ature (above freezing). Consequently, it generally accepted that this type of sensor indicates relative humidity with respect to water at all temperatures temperature (including below freezing). 4 Vapor concentration Ice produces a lower vapor pressure than liquid water. Therefore, when 5 Specific humidity ice is present, saturation occurs at a relative humidity of less than 100 %. 6 Enthalpy For instance, a humidity reading of 75 %RH at a temperature of -30°C corre - 7 Mixing ratio sponds to saturation above ice. by weight 2 Dew point / Frost point temperature The dew point temperature of moist air at the temperature T, pressure P b and mixing ratio r is the temperature to which air must be cooled in order to be saturated with respect to water (liquid). The frost point temperature of moist air at temperature T, pressure P b and mixing ratio r is the temperature to which air must be cooled in order to be saturated with respect to ice. Magnus Formula for dew point (over water): Td = (243.12 x ln (pw/611.2)) / (17.62 - ln (pw/611.2)) Frost point (over ice): Tf = (272.62 x ln (pi/611.2)) / (22.46 -
  • Cygwin User's Guide

    Cygwin User's Guide

    Cygwin User’s Guide Cygwin User’s Guide ii Copyright © Cygwin authors Permission is granted to make and distribute verbatim copies of this documentation provided the copyright notice and this per- mission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this documentation under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this documentation into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. Cygwin User’s Guide iii Contents 1 Cygwin Overview 1 1.1 What is it? . .1 1.2 Quick Start Guide for those more experienced with Windows . .1 1.3 Quick Start Guide for those more experienced with UNIX . .1 1.4 Are the Cygwin tools free software? . .2 1.5 A brief history of the Cygwin project . .2 1.6 Highlights of Cygwin Functionality . .3 1.6.1 Introduction . .3 1.6.2 Permissions and Security . .3 1.6.3 File Access . .3 1.6.4 Text Mode vs. Binary Mode . .4 1.6.5 ANSI C Library . .4 1.6.6 Process Creation . .5 1.6.6.1 Problems with process creation . .5 1.6.7 Signals . .6 1.6.8 Sockets . .6 1.6.9 Select . .7 1.7 What’s new and what changed in Cygwin . .7 1.7.1 What’s new and what changed in 3.2 .
  • Μmachine Definitions

    Μmachine Definitions

    Machine/Code For the final part of the CS450 project, you are to complete a fully functional Pascal compiler. Since it would be impractical to have you generate assembly code for a real machine (with all the intricacies of the target machine), we have created a virtual machine that has been designed specifically for a Pascal compiler. The Machine (and is associated assembly language Code) greatly simplifies the task of code generation while still requiring you to handle many of the problems faced by other compiler writers. At this point in time, you should have written a scanner and parser for Pascal, should be working on the symbol table and should be thinking about semantic processing and code generation. The following information about the Machine and Code is provided to assist you in your design and implementation of the remaining parts of the Pascal compiler project: Machine Specification: The Machine is a virtual machine (simulated by a program) with the following hardware characteristics: Separate instruction space (for assembly code) and RAM (for data storage/retrieval) 10 general purpose registers (D0 - D9) Special stack pointer register (SP) The Machine is a stack-based machine; all memory is allocated/deallocated on the data stack residing in RAM: The data stack supports types: Integer, Float/Fixed, Strings. All data types have the same size of 1. The data stack grows upwards (starts at 0, pushes increment the SP, pops decrement the SP) Supported Data Types Integer: As defined in the Pascal tokens document. Size: 1. Float/Fixed: Numbers represented as floating point or fixed point are supported and have a size of 1.
  • Securing Embedded Systems: Analyses of Modern Automotive Systems and Enabling Near-Real Time Dynamic Analysis

    Securing Embedded Systems: Analyses of Modern Automotive Systems and Enabling Near-Real Time Dynamic Analysis

    Securing Embedded Systems: Analyses of Modern Automotive Systems and Enabling Near-Real Time Dynamic Analysis Karl Koscher A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy University of Washington 2014 Reading Committee: Tadayoshi Kohno, Chair Gaetano Borriello Shwetak Patel Program Authorized to Offer Degree: Computer Science and Engineering © Copyright 2014 Karl Koscher University of Washington Abstract Securing Embedded Systems: From Analyses of Modern Automotive Systems to Enabling Dynamic Analysis Karl Koscher Chair of the Supervisory Committee: Associate Professor Tadayoshi Kohno Department of Computer Science and Engineering Today, our life is pervaded by computer systems embedded inside everyday products. These embedded systems are found in everything from cars to microwave ovens. These systems are becoming increasingly sophisticated and interconnected, both to each other and to the Internet. Unfortunately, it appears that the security implications of this complexity and connectivity have mostly been overlooked, even though ignoring security could have disastrous consequences; since embedded systems control much of our environment, compromised systems could be used to inflict physical harm. This work presents an analysis of security issues in embedded systems, including a comprehensive security analysis of modern automotive systems. We hypothesize that dynamic analysis tools would quickly discover many of the vulnerabilities we found. However, as we will discuss, there
  • Root Filesystem

    Root Filesystem

    >>> Operating Systems And Applications For Embedded Systems >>> Root Filesystem Name: Mariusz Naumowicz Date: 27 sierpnia 2018 [~]$ _ [1/21] >>> Plan 1. Root Filesystem Useful System Filesystem Hierarchy Standard (FHS) Staging directory 2. Programs The init program Shell Utilities BusyBox ToyBox Libraries Reducing size by stripping Device nodes The proc and sysfs flesystems Mounting flesystems Additional reading Standalone ramdisk Minimizing size Booting with QEMU Additional reading [~]$ _ [2/21] >>> Useful System * init: The program that starts everything off, usually by running a series of scripts. * shell: Needed to give you a command prompt but, more importantly, to run the shell scripts called by init and other programs. * daemons: Various server programs, started by init. * libraries: Usually, the programs mentioned so far are linked with shared libraries which must be present in the root filesystem. * Configuration files: The configuration for init and other daemons is stored in a series of ASCII text files, usually in the /etc directory. * Device nodes: The special files that give access to various device drivers. * /proc and /sys: Two pseudo filesystems that represent kernel data structures as a hierarchy of directories and files. Many programs and library functions read these files. * kernel modules: If you have configured some parts of your kernel to be modules, they will be here, usually in /lib/modules/[kernel version]. [1. Root Filesystem]$ _ [3/21] >>> Filesystem Hierarchy Standard (FHS) * /bin: programs essential for all
  • Yocto-Slides.Pdf

    Yocto-Slides.Pdf

    Yocto Project and OpenEmbedded Training Yocto Project and OpenEmbedded Training © Copyright 2004-2021, Bootlin. Creative Commons BY-SA 3.0 license. Latest update: October 6, 2021. Document updates and sources: https://bootlin.com/doc/training/yocto Corrections, suggestions, contributions and translations are welcome! embedded Linux and kernel engineering Send them to [email protected] - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 1/296 Rights to copy © Copyright 2004-2021, Bootlin License: Creative Commons Attribution - Share Alike 3.0 https://creativecommons.org/licenses/by-sa/3.0/legalcode You are free: I to copy, distribute, display, and perform the work I to make derivative works I to make commercial use of the work Under the following conditions: I Attribution. You must give the original author credit. I 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. I For any reuse or distribution, you must make clear to others the license terms of this work. I 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. Document sources: https://github.com/bootlin/training-materials/ - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 2/296 Hyperlinks in the document There are many hyperlinks in the document I Regular hyperlinks: https://kernel.org/ I Kernel documentation links: dev-tools/kasan I Links to kernel source files and directories: drivers/input/ include/linux/fb.h I Links to the declarations, definitions and instances of kernel symbols (functions, types, data, structures): platform_get_irq() GFP_KERNEL struct file_operations - Kernel, drivers and embedded Linux - Development, consulting, training and support - https://bootlin.com 3/296 Company at a glance I Engineering company created in 2004, named ”Free Electrons” until Feb.
  • 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

    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.
  • Cross-Compiler Bipartite Vulnerability Search

    Cross-Compiler Bipartite Vulnerability Search

    electronics Article Cross-Compiler Bipartite Vulnerability Search Paul Black * and Iqbal Gondal Internet Commerce Security Laboratory (ICSL), Federation University, Ballarat 3353, Australia; [email protected] * Correspondence: [email protected] Abstract: Open-source libraries are widely used in software development, and the functions from these libraries may contain security vulnerabilities that can provide gateways for attackers. This paper provides a function similarity technique to identify vulnerable functions in compiled programs and proposes a new technique called Cross-Compiler Bipartite Vulnerability Search (CCBVS). CCBVS uses a novel training process, and bipartite matching to filter SVM model false positives to improve the quality of similar function identification. This research uses debug symbols in programs compiled from open-source software products to generate the ground truth. This automatic extraction of ground truth allows experimentation with a wide range of programs. The results presented in the paper show that an SVM model trained on a wide variety of programs compiled for Windows and Linux, x86 and Intel 64 architectures can be used to predict function similarity and that the use of bipartite matching substantially improves the function similarity matching performance. Keywords: malware similarity; function similarity; binary similarity; machine-learning; bipar- tite matching 1. Introduction Citation: Black, P.; Gondal, I. Cross-Compiler Bipartite Function similarity techniques are used in the following activities, the triage of mal- Vulnerability Search. Electronics 2021, ware [1], analysis of program patches [2], identification of library functions [3], analysis of 10, 1356. https://doi.org/10.3390/ code authorship [4], the identification of similar function pairs to reduce manual analysis electronics10111356 workload, [5], plagiarism analysis [6], and for vulnerable function identification [7–9].
  • Linux Cheat Sheet

    Linux Cheat Sheet

    1 of 4 ########################################### # 1.1. File Commands. # Name: Bash CheatSheet # # # # A little overlook of the Bash basics # ls # lists your files # # ls -l # lists your files in 'long format' # Usage: A Helpful Guide # ls -a # lists all files, including hidden files # # ln -s <filename> <link> # creates symbolic link to file # Author: J. Le Coupanec # touch <filename> # creates or updates your file # Date: 2014/11/04 # cat > <filename> # places standard input into file # Edited: 2015/8/18 – Michael Stobb # more <filename> # shows the first part of a file (q to quit) ########################################### head <filename> # outputs the first 10 lines of file tail <filename> # outputs the last 10 lines of file (-f too) # 0. Shortcuts. emacs <filename> # lets you create and edit a file mv <filename1> <filename2> # moves a file cp <filename1> <filename2> # copies a file CTRL+A # move to beginning of line rm <filename> # removes a file CTRL+B # moves backward one character diff <filename1> <filename2> # compares files, and shows where differ CTRL+C # halts the current command wc <filename> # tells you how many lines, words there are CTRL+D # deletes one character backward or logs out of current session chmod -options <filename> # lets you change the permissions on files CTRL+E # moves to end of line gzip <filename> # compresses files CTRL+F # moves forward one character gunzip <filename> # uncompresses files compressed by gzip CTRL+G # aborts the current editing command and ring the terminal bell gzcat <filename> #
  • Operating System Components for an Embedded Linux System

    Operating System Components for an Embedded Linux System

    INSTITUTEFORREAL-TIMECOMPUTERSYSTEMS TECHNISCHEUNIVERSITATM¨ UNCHEN¨ PROFESSOR G. F ARBER¨ Operating System Components for an Embedded Linux System Martin Hintermann Studienarbeit ii Operating System Components for an Embedded Linux System Studienarbeit Executed at the Institute for Real-Time Computer Systems Technische Universitat¨ Munchen¨ Prof. Dr.-Ing. Georg Farber¨ Advisor: Prof.Dr.rer.nat.habil. Thomas Braunl¨ Author: Martin Hintermann Kirchberg 34 82069 Hohenschaftlarn¨ Submitted in February 2007 iii Acknowledgements At first, i would like to thank my supervisor Prof. Dr. Thomas Braunl¨ for giving me the opportunity to take part at a really interesting project. Many thanks to Thomas Sommer, my project partner, for his contribution to our good work. I also want to thank also Bernard Blackham for his assistance by email and phone at any time. In my opinion, it was a great cooperation of all persons taking part in this project. Abstract Embedded systems can be found in more and more devices. Linux as a free operating system is also becoming more and more important in embedded applications. Linux even replaces other operating systems in certain areas (e.g. mobile phones). This thesis deals with the employment of Linux in embedded systems. Various architectures of embedded systems are introduced and the characteristics of common operating systems for these devices are reviewed. The architecture of Linux is examined by looking at the particular components such as kernel, standard C libraries and POSIX tools for embedded systems. Furthermore, there is a survey of real-time extensions for the Linux kernel. The thesis also treats software development for embedded Linux ranging from the prerequi- sites for compiling software to the debugging of binaries.