DOCSLIB.ORG

The DENX U-Boot and Linux Guide (DULG) for M28evk

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The DENX U-Boot and Linux Guide (DULG) for M28evk The DENX U-Boot and Linux Guide (DULG) for m28evk Table of contents: • 1. Abstract • 2. Introduction ♦ 2.1. Copyright ♦ 2.2. Disclaimer ♦ 2.3. Availability ♦ 2.4. Credits ♦ 2.5. Translations ♦ 2.6. Feedback ♦ 2.7. Conventions • 3. Embedded Linux Development Kit ♦ 3.1. ELDK Availability ♦ 3.2. ELDK Getting Help ♦ 3.3. Supported Host Systems ♦ 3.4. Supported Target Architectures ♦ 3.5. Installation ◊ 3.5.1. Product Packaging ◊ 3.5.2. Downloading the ELDK ◊ 3.5.3. Initial Installation ◊ 3.5.4. Installation and Removal of Individual Packages ◊ 3.5.5. Removal of the Entire Installation ♦ 3.6. Working with ELDK ◊ 3.6.1. Switching Between Multiple Installations ♦ 3.7. Mounting Target Components via NFS ♦ 3.8. Rebuilding ELDK Components ◊ 3.8.1. ELDK Source Distribution ◊ 3.8.2. Rebuilding Target Packages ◊ 3.8.3. Rebuilding ELDT Packages ♦ 3.9. ELDK Packages ◊ 3.9.1. List of ELDT Packages ◊ 3.9.2. List of Target Packages ♦ 3.10. Rebuilding the ELDK from Scratch ◊ 3.10.1. ELDK Build Process Overview ◊ 3.10.2. Setting Up ELDK Build Environment ◊ 3.10.3. build.sh Usage ◊ 3.10.4. Format of the cpkgs.lst and tpkgs.lst Files • 4. System Setup ♦ 4.1. Serial Console Access ♦ 4.2. Configuring the "cu" command ♦ 4.3. Configuring the "kermit" command ♦ 4.4. Using the "minicom" program ♦ 4.5. Permission Denied Problems ♦ 4.6. Configuration of a TFTP Server ♦ 4.7. Configuration of a BOOTP / DHCP Server ♦ 4.8. Configuring a NFS Server • 5. Das U-Boot ♦ 5.1. Current Versions ♦ 5.2. Unpacking the Source Code ♦ 5.3. Configuration The DENX U-Boot and Linux Guide (DULG) for m28evk 1 ♦ 5.4. Installation ◊ 5.4.1. Before You Begin ⋅ 5.4.1.1. Installation Requirements ⋅ 5.4.1.2. Board Identification Data ◊ 5.4.2. Installation Using a BDM/JTAG Debugger ◊ 5.4.3. Installation using U-Boot ♦ 5.5. Tool Installation ♦ 5.6. Initialization ♦ 5.7. Initial Steps ♦ 5.8. The First Power-On ♦ 5.9. U-Boot Command Line Interface ◊ 5.9.1. Information Commands ⋅ 5.9.1.1. bdinfo - print Board Info structure ⋅ 5.9.1.2. coninfo - print console devices and informations ⋅ 5.9.1.3. flinfo - print FLASH memory information ⋅ 5.9.1.4. iminfo - print header information for application image ⋅ 5.9.1.5. help - print online help ◊ 5.9.2. Memory Commands ⋅ 5.9.2.1. base - print or set address offset ⋅ 5.9.2.2. crc32 - checksum calculation ⋅ 5.9.2.3. cmp - memory compare ⋅ 5.9.2.4. cp - memory copy ⋅ 5.9.2.5. md - memory display ⋅ 5.9.2.6. mm - memory modify (auto-incrementing) ⋅ 5.9.2.7. mtest - simple RAM test ⋅ 5.9.2.8. mw - memory write (fill) ⋅ 5.9.2.9. nm - memory modify (constant address) ⋅ 5.9.2.10. loop - infinite loop on address range ◊ 5.9.3. Flash Memory Commands ⋅ 5.9.3.1. cp - memory copy ⋅ 5.9.3.2. flinfo - print FLASH memory information ⋅ 5.9.3.3. erase - erase FLASH memory ⋅ 5.9.3.4. protect - enable or disable FLASH write protection ⋅ 5.9.3.5. mtdparts - define a Linux compatible MTD partition scheme ⋅ 5.9.3.6. UBI Usage in U-Boot ◊ 5.9.4. Execution Control Commands ⋅ 5.9.4.1. source - run script from memory ⋅ 5.9.4.2. bootm - boot application image from memory ⋅ 5.9.4.3. go - start application at address 'addr' ◊ 5.9.5. Download Commands ⋅ 5.9.5.1. bootp - boot image via network using BOOTP/TFTP protocol ⋅ 5.9.5.2. dhcp - invoke DHCP client to obtain IP/boot params ⋅ 5.9.5.3. loadb - load binary file over serial line (kermit mode) ⋅ 5.9.5.4. loads - load S-Record file over serial line ⋅ 5.9.5.5. tftpboot- boot image via network using TFTP protocol ◊ 5.9.6. Environment Variables Commands ⋅ 5.9.6.1. printenv- print environment variables ⋅ 5.9.6.2. saveenv - save environment variables to persistent storage ⋅ 5.9.6.3. setenv - set environment variables ⋅ 5.9.6.4. run - run commands in an environment variable ⋅ 5.9.6.5. bootd - boot default, i.e., run 'bootcmd' ◊ 5.9.7. Flattened Device Tree support ⋅ 5.9.7.1. fdt addr - select FDT to work on ⋅ 5.9.7.2. fdt list - print one level The DENX U-Boot and Linux Guide (DULG) for m28evk 2 ⋅ 5.9.7.3. fdt print - recursive print ⋅ 5.9.7.4. fdt mknode - create new nodes ⋅ 5.9.7.5. fdt set - set node properties ⋅ 5.9.7.6. fdt rm - remove nodes or properties ⋅ 5.9.7.7. fdt move - move FDT blob to new address ⋅ 5.9.7.8. fdt chosen - fixup dynamic info ◊ 5.9.8. Special Commands ⋅ 5.9.8.1. i2c - I2C sub-system ◊ 5.9.9. Storage devices ⋅ 5.9.9.1. MMC devices ⋅ 5.9.9.2. NAND devices • 5.9.9.2.1. nand bad - show bad block information • 5.9.9.2.2. nand erase - erase region • 5.9.9.2.3. nand write - write to NAND device • 5.9.9.2.4. nand read - read from NAND device ◊ 5.9.10. Miscellaneous Commands ⋅ 5.9.10.1. date - get/set/reset date & time ⋅ 5.9.10.2. echo - echo args to console ⋅ 5.9.10.3. reset - Perform RESET of the CPU ⋅ 5.9.10.4. sleep - delay execution for some time ⋅ 5.9.10.5. version - print monitor version ⋅ 5.9.10.6. ? - alias for 'help' ♦ 5.10. U-Boot Environment Variables ♦ 5.11. U-Boot Scripting Capabilities ♦ 5.12. U-Boot Standalone Applications ◊ 5.12.1. "Hello World" Demo ◊ 5.12.2. Timer Demo ♦ 5.13. U-Boot Image Formats ♦ 5.14. U-Boot Advanced Features ◊ 5.14.1. Boot Count Limit • 6. Embedded Linux Configuration ♦ 6.1. Download and Unpack the Linux Kernel Sources ♦ 6.2. Kernel Configuration and Compilation ♦ 6.3. Installation • 7. Booting Embedded Linux ♦ 7.1. Introduction ♦ 7.2. Flattened Device Tree Blob ♦ 7.3. Passing Kernel Arguments ♦ 7.4. Boot Arguments Unleashed ♦ 7.5. Networked Operation with Root Filesystem over NFS ◊ 7.5.1. Bootlog of tftp'd Linux kernel with Root Filesystem over NFS ♦ 7.6. Boot from NAND Flash Memory ♦ 7.7. Standalone Operation with Ramdisk Image • 8. Building and Using Modules • 9. Advanced Topics ♦ 9.1. Flash Filesystems ◊ 9.1.1. Memory Technology Devices ◊ 9.1.2. Journalling Flash File System ◊ 9.1.3. Second Version of JFFS ◊ 9.1.4. Compressed ROM Filesystem ◊ 9.1.5. UBI and UBIFS file systems ⋅ 9.1.5.1. Create Device Files ⋅ 9.1.5.2. Using UBI on NAND Flash: ⋅ 9.1.5.3. Creating UBIFS File System Images The DENX U-Boot and Linux Guide (DULG) for m28evk 3 • 9.1.5.3.1. Determining the Parameters of the used Flash Types: • 9.1.5.3.2. Create some Test File System Hierarchy • 9.1.5.3.3. Installing UBIFS images into existing UBI Volume: • 9.1.5.3.4. Installing UBI images (if no UBI Volumes exist): ♦ 9.2. The TMPFS Virtual Memory Filesystem ◊ 9.2.1. Mount Parameters ◊ 9.2.2. Kernel Support for tmpfs ◊ 9.2.3. Usage of tmpfs in Embedded Systems ♦ 9.3. Using MultiMediaCards in Linux ♦ 9.4. Splash Screen Support in Linux ♦ 9.5. Root File System: Design and Building ◊ 9.5.1. Root File System on a Ramdisk ◊ 9.5.2. Root File System on a JFFS2 File System ◊ 9.5.3. Root File System on a cramfs File System ◊ 9.5.4. Root File System on a Read-Only ext2 File System ◊ 9.5.5. Root File System on a Flash Card ◊ 9.5.6. Root File System in a Read-Only File in a FAT File System ♦ 9.6. Root File System Selection ♦ 9.7. Overlay File Systems ♦ 9.8. The Persistent RAM File system (PRAMFS) ◊ 9.8.1. Mount Parameters ◊ 9.8.2. Example • 10. Debugging ♦ 10.1. Debugging of U-Boot ◊ 10.1.1. Debugging of U-Boot Before Relocation ◊ 10.1.2. Debugging of U-Boot After Relocation ♦ 10.2. Linux Kernel Debugging ◊ 10.2.1. Linux Kernel and Statically Linked Device Drivers ◊ 10.2.2. Dynamically Loaded Device Drivers (Modules) ◊ 10.2.3. GDB Macros to Simplify Module Loading ♦ 10.3. GDB Startup File and Utility Scripts ♦ 10.4. Tips and Tricks ♦ 10.5. Application Debugging ◊ 10.5.1. Local Debugging ◊ 10.5.2. Remote Debugging ♦ 10.6. Debugging with Graphical User Interfaces • 11. Simple Embedded Linux Framework • 12. Books, Mailing Lists, Links, etc. ♦ 12.1. Application Notes ♦ 12.2. Further Reading ◊ 12.2.1. Upstreaming ◊ 12.2.2. License Issues ◊ 12.2.3. Linux kernel ◊ 12.2.4. General Linux / Unix programming ◊ 12.2.5. Network Programming ◊ 12.2.6. C++ programming ◊ 12.2.7. Java programming ◊ 12.2.8. Internationalization And Character Sets ◊ 12.2.9. ARM Architecture Programming ◊ 12.2.10. Power Architecture® Programming ◊ 12.2.11. Embedded Topics ♦ 12.3. Mailing Lists ♦ 12.4. Links ♦ 12.5. Tools The DENX U-Boot and Linux Guide (DULG) for m28evk 4 • 13. Appendix ♦ 13.1. Flat Device Tree ♦ 13.2. BDI2000 Configuration file • 14. FAQ - Frequently Asked Questions ♦ 14.1. ELDK ◊ 14.1.1. ELDK Installation under FreeBSD ◊ 14.1.2. ELDK Installation Hangs ◊ 14.1.3. .gvfs: Permission Denied ◊ 14.1.4. Installation on Local Harddisk ◊ 14.1.5. System Include Files Missing ◊ 14.1.6. patch: command not found ◊ 14.1.7. ELDK Include Files Missing ◊ 14.1.8. Using the ELDK on a 64 bit platform ◊ 14.1.9.
Load more

Recommended publications
  • Stackable File Systems As a Security Tool
    Stackable File Systems as a Security Tool Erez Zadok Computer Science Department, Columbia University [email protected] CUCS-036-99 Abstract Programmers often prefer to use existing system security services, such as file system security, rather than im- plement their own in an application. Traditional Unix security is generally considered inadequate and few operating systems offer enhanced security features such as ACLs[24] or immutable files[12]. Additional file system security features are always sought, but implementing them is a difficult task because modifying and porting existing file systems is costly or not possible. We advocate adding new security features using stackable file systems. As a starting point, we propose a portable, stackable template called the wrapper file system or Wrapfs, a minimal file system from which a wide range of file systems can be prototyped. A developer can modify a copy of the template and add only that which is necessary to achieve the desired functionality. The Wrapfs template takes care of kernel internals, freeing the developer from the details of operating system internals. Wrapfs imposes an overhead of only 5–7%. This paper describes the design, implementation, and porting of Wrapfs. We discuss several prototype file sys- tems written using Wrapfs that illustrate the ease with which security features can be implemented. The examples demonstrate security features such as encryption, access control, intrusion detection, intrusion avoidance, and analy- sis. 1 Introduction Security has become and integral part of computing in recent years. To provide the strongest possible security to users, security solutions sometimes consume a large amount of resources, and may inconvenience their users too much.
    [Show full text]
  • A Steganographic File System for the Linux Kernel
    A Steganographic File System for the Linux Kernel by Ashley Morgan Anderson The University of Exeter COM3401 Individual Project 11th August 2007 Abstract Encryption is all around us these days, yet the security of private data on home computers is overlooked by many. The presence of cipher-text — in some instances — can make things worse, therefore the only way to overcome this is to hide the data. The Ancient Greeks knew about this risk and as such fabricated some of the most ingenious methods of steganography ever used. However, steganography has come along way in the last 3000 years, and is more important today than ever before (due to tightening restrictions governing encryption). This paper looks at how different mediums have been used to ensure messages and data remain private, as well as proposing a new file system which takes care of hiding files for the user. Whilst not the first, it does include many unique features which are intended to provide a more natural interface. I certify that all material in this project which is not my own work has been identified. ...................................... A.M. Anderson Contents 1 Introduction 1 2 Background 2 2.1 Steganography . 2 2.2 File Systems . 4 2.3 Steganographic File Systems . 6 3 Design 11 3.1 Implemented Design . 11 3.2 Potential Driver Types . 13 3.3 Initial File System . 15 3.4 Encryption . 15 3.5 A Discarded Design . 16 4 Development 17 4.1 The Tools . 17 4.2 The Process . 18 5 Testing 19 5.1 Progressive . 19 5.2 Forensic Analysis .
    [Show full text]
  • Cryptographic File Systems Performance: What You Don't Know Can Hurt You Charles P
    Cryptographic File Systems Performance: What You Don't Know Can Hurt You Charles P. Wright, Jay Dave, and Erez Zadok Stony Brook University Appears in the proceedings of the 2003 IEEE Security In Storage Workshop (SISW 2003) Abstract interact with disks, caches, and a variety of other com- plex system components — all having a dramatic effect Securing data is more important than ever, yet cryp- on performance. tographic file systems still have not received wide use. In this paper we perform a real world performance One barrier to the adoption of cryptographic file systems comparison between several systems that are used is that the performance impact is assumed to be too high, to secure file systems on laptops, workstations, and but in fact is largely unknown. In this paper we first moderately-sized file servers. We also emphasize multi- survey available cryptographic file systems. Second, programming workloads, which are not often inves- we perform a performance comparison of a representa- tigated. Multi-programmed workloads are becoming tive set of the systems, emphasizing multiprogrammed more important even for single user machines, in which workloads. Third, we discuss interesting and counterin- Windowing systems are often used to run multiple appli- tuitive results. We show the overhead of cryptographic cations concurrently. We expect cryptographic file sys- file systems can be minimal for many real-world work- tems to become a commodity component of future oper- loads, and suggest potential improvements to existing ating systems. systems. We have observed not only general trends with We present results from a variety of benchmarks, an- each of the cryptographic file systems we compared but alyzing the behavior of file systems for metadata op- also anomalies based on complex interactions with the erations, raw I/O operations, and combined with CPU operating system, disks, CPUs, and ciphers.
    [Show full text]
  • Hello Marte OS Using an Emulator Daniel Sangorrin [email protected]
    Hello MaRTE OS using an emulator Daniel Sangorrin [email protected] 2009-3-4 Revision History Revision 1.3 2009-3-4 Revised by: dsl Add mtools for mounting the images. Update installation instructions referencing INSTALL file. Revision 1.2 2007-6-15 Revised by: dsl Added the process to create a FAT16 image file for QEMU Revision 1.1 2007-6-9 Revised by: dsl Updated to MaRTE OS v1.6 snapshot This document tries to introduce people to MaRTE OS in a very simple way. Table of Contents 1. Preface........................................................................................................................................................................2 1.1. Feedback.........................................................................................................................................................2 2. Let’s see MaRTE OS running!.................................................................................................................................2 2.1. Install the emulator QEMU............................................................................................................................2 2.2. ...and run these MaRTE OS Demos! ..............................................................................................................2 3. Hello MaRTE! ...........................................................................................................................................................3 3.1. The compiler GNAT-GPL ..............................................................................................................................3
    [Show full text]
  • Linux Based Live CD on Optical Disks
    Pobrane z czasopisma Annales AI- Informatica http://ai.annales.umcs.pl Data: 26/09/2021 15:23:08 Annales UMCS Annales UMCS Informatica AI 5 (2006) 29-36 Informatica Lublin-Polonia Sectio AI http://www.annales.umcs.lublin.pl/ Linux based Live CD on optical disks 1 2* Michał Chromiak , Andrzej Góźdź 1Institute of Mathematics, Maria Curie-Skłodowska University, Pl. M.Curie-Skłodowskiej 1, 20-031 Lublin, Poland 2Institute of Physics, Maria Curie-Skłodowska University, Pl. M.Curie-Skłodowskiej 1, 20-031 Lublin, Poland Abstract We present an introduction to LiveCD system remastering based on a prospective UnionFS filesystem. 1. Introduction Regarding increasing popularity of the LiveCD distributions1 of a Linux system we compile the essential knowledge of how the LiveCD works (based on many rather scattered documents [1-8]) to facilitate preparation of the specialized distributions of systems based on this idea. We describe one of the most efficient ways of system architecture managing using UnionFS. All steps of the procedure were tested using laptops which have often more exotic hardware than desktopUMCS computers. The possibility of booting a PC from a CD/DVD ROM has raised several possibilities, including the most important one, namely, the possibility of running the required system or programs independently of the actual operational system, configuration, and resources of the PC. The self-configuring CD/DVD ROMs can be also useful for administrative purposes and as the rescue disks. The LiveCD distributions allow for cheap and effective use of the PCs as the special servers, routers and other active elements over the network. This idea of the LiveCD systems is based on the possibility opened by the El Torito extension to the standard ISO 9660 system and the Linux kernel capabilities.
    [Show full text]
  • Bootable Kubuntu
    Building a casper-rw USB for Kubuntu/Ubuntu 10.04 2010/09/01 Section 1 - Some File Types Everything in Linux is a File or a Process. ISO Image Files An .ISO image is an archive file with a .iso file extension and has a file format (ISO 9660) defined by the International Organization for Standardization (ISO). An .ISO file is also called a ©disk image© file when it contains the contents of a CD or DVD. The main features of an ISO image file are that it is a compressed block by block copy of the original files on a hard drive and it can be easily burned to a DVD or CD. Device Files (or Special Files) a device file or special file is an interface for a device driver; it presents in a file system as if it were an ordinary file. Device files can be found in the directory ©/dev© Character Device Files (also called Serial Devices) Character device files are ©device nodes© used to drive physical devices (such as mice& keyboards) one byte (character) at a time.. Block Device Files Block device files are ©device nodes© through which the operating system moves data in the form of random addressable data blocks (e.g. 512 byte disk blocks) to physical devices such as hard disks, CD-ROM drives, or memory-regions. Pseudo-Devices Device nodes on are not always associated with physical devices. Nodes that lack an association with a physical device are called pseudo-devices. Psuedo-devices provide various functions handled by the operating system.
    [Show full text]
  • Key Management for Transcrypt
    Key Management for Transcrypt by Abhijit Bagri DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING INDIAN INSTITUTE OF TECHNOLOGY, KANPUR May 2007 i Key Management for TransCrypt A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of Master of Technology by Abhijit Bagri to the DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING INDIAN INSTITUTE OF TECHNOLOGY,KANPUR May 2007 ii CERTIFICATE It is certified that the work contained in the thesis entitled " Key Management for 1ran- sCrypt" by Abhijit Bagri has been carried out under my supervision and that this work has not been submitted elsewhere for a degree. Dr. Rajat Moona Dr. Dheeraj Sanghi Department of Computer Science Department of Computer Science & Engineering, & Engineering, Indian Institute of Technology Kanpur, Indian Institute of Technology Kanpur, Kanpur-208016. Kanpur-208016. iii Abstract With data storage and processing snowballing into a necessity from being an efficient part of any business process or organization, the need for securing storage at various degrees of granularity is gaining considerable interest. The challenge in designing an encrypted filesys- tem stems from balancing performance, security perception, ease of usage and enterprise level deployability. Often, the most secure solutions may not even be the best solution either due to hit on performance or due to decreased usability. Further, narrowing the trust circle to exclude even hitherto trusted system administrators makes creating an encrypted filesystem a huge engineering exercise. In this thesis, we talk about key management issues in TransCrypt[21], an encrypted file system design with smallest trust circle to the best of our knowledge. We provide an entire architecture with utilities like secure key stores, and their management through libraries in- side and outside the kernel space.
    [Show full text]
  • Steganographic File System Based on Jpeg Files 1
    Ø Ñ ÅØÑØÐ ÈÙ ÐØÓÒ× DOI: 10.2478/tmmp-2013-0036 Tatra Mt. Math. Publ. 57 (2013), 65–83 STEGANOGRAPHIC FILE SYSTEM BASED ON JPEG FILES Matu´ˇsJokay´ — Martin Koˇsdy ABSTRACT. A steganographic system provides a hidden communication chan- nel in background of a public channel. The existence of the hidden channel must remain secret, i.e. the adversary cannot decide whether the public channel con- tains any covert information or not. The public channel that is used in construc- tion of a steganographic system can often be embedded in a static file (medium), that is called a carrier (if the steganographic information is present). Most of the current research focuses on a single medium. The most suitable types of media, such as images or music files, contain a lot of redundancy. Small changes in the redundant parts are not easily detected. However, new methods for the detection of this information are developed along with the new algorithms for embedding the hidden information. Our work describes a new steganographic system design, where the hidden information is spread among many static images in a form of a virtual steganographic filesystem. We note that the implementation of the system must also take into account “steganographic side-channels”, i.e., some in- formation channels that are present in the operating system (in our case Linux, and Android) that leak information about the presence of the hidden channel. 1. Introduction The steganography has advanced tremendously in the last decade. Currently, there exist numerous sophisticated steganographic techniques of hiding the se- cret data in the various kinds of cover media.
    [Show full text]
  • LVM2 - Storage Virtualization Milan Brož [email protected]
    LVM2 - storage virtualization Milan Brož [email protected] Linux weekend 2007 LVM2 – storage virtualization Why storage virtualization ? . Abstraction over physical storage . Simplify management of storage resources . High-Availability (on the fly) operation . Flexibility - resize, relocation, optimize, ... Scalability - no physical devices restriction . Security - RAID, online snapshots . Reduce operation costs Linux weekend 2007 1 LVM2 – storage virtualization Storage virtualization in Linux technology overview CLUSTER LOCAL shared storage storage cluster locking DLM ext3 GFS2 XFS filesystem CLVM LVM2 Volume management MD multipath FC iSCSI SATA physical storage SCSI GNBD Linux weekend 2007 2 LVM2 – storage virtualization LVM2 – Logical volume manager . Layer of abstraction over the physical storage . Provides Logical Volumes used by filesystems (or directly by applications) . Logical Volume is block device . Logical Volume ~ similar to disk partition . Hides physical hardware configuration Linux weekend 2007 3 LVM2 – storage virtualization Linux LVM . LVM1 – only in Linux kernel 2.4 major part of functionality in kernel, design inspired by HP-UX LVM . LVM2 - more generic concept LVM1 commands compatible, can use LVM1 metadata ● KERNEL driver (Device mapper) ● USERSPACE toolset (LVM2) Linux weekend 2007 4 LVM2 – storage virtualization MD versus DM/LVM2 . MD is multi-disk kernel layer ● it can create new block devices from existing discs ● linear, raid 0,1,4,5,6 ● very stable, management through mdadm utility . DM (device mapper) is kernel driver ● Generic block device mapping utility, you can combine (almost) all possible targets and create new block device . LVM2 is generic volume management ● you can combine physical discs, MD and DM devices into volumes Linux weekend 2007 5 LVM2 – storage virtualization Device mapper ..
    [Show full text]
  • Embedded Linux System Design and Development
    Au0586 half title page 11/17/05 2:05 PM Page 1 EMBEDDED LINUX SYSTEM DESIGN AND DEVELOPMENT Au0586 title page 11/17/05 2:04 PM Page 1 EMBEDDED LINUX SYSTEM DESIGN AND DEVELOPMENT TEAM FLY P. Raghavan • Amol Lad • Sriram Neelakandan Boca Raton New York Published in 2006 by Auerbach Publications Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2006 by Taylor & Francis Group, LLC Auerbach is an imprint of Taylor & Francis Group No claim to original U.S. Government works Printed in the United States of America on acid-free paper 10987654321 International Standard Book Number-10: 0-8493-4058-6 (Hardcover) International Standard Book Number-13: 978-0-8493-4058-1 (Hardcover) Library of Congress Card Number 2005048179 This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or for the consequences of their use. No part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.copyright.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc.
    [Show full text]
  • A Virtual Filesystem Layer Implementation in the XV6 Operating System
    Caio Araújo Neponoceno de Lima A Virtual Filesystem Layer implementation in the XV6 Operating System Salvador - BA, Brazil 2016 Caio Araújo Neponoceno de Lima A Virtual Filesystem Layer implementation in the XV6 Operating System A monograph submitted to the Department of Computer Science of the Federal University of Bahia in partial fulfilment of the require- ments for the Degree of Bachelor in Computer Science. Federal University of Bahia – UFBA Institute of Mathematics Department of Computer Science Advisor: Maurício Pamplona Segundo Salvador - BA, Brazil 2016 Resumo Este trabalho está apresentando uma implementação de um Virtual File System (VFS) que permite mais de um sistema de arquivos coexistir no XV6. Como uma prova de conceito, nós também apresentamos uma implementação básica do sistema de arquivos EXT2, um dos sistemas de arquivos mais populares entre usuários Linux na década de 90. O principal objetivo deste trabalho é documentar uma fonte de conhecimento simples e prática sobre desenvolvimento de sistemas de arquivos para ambientes Unix. Com a simplicidade do XV6, esta implementação do VFS torna possível adicionar suporte a novos sistemas de arquivos para o mesmo com o mínimo de esforço. Keywords: VFS. Operating Systems. Filesystems. Unix. Abstract This work is presenting an implementation of a Virtual Filesystem Layer (VFS) to enable more than one filesystem coexist over the XV6. As a proof of concept, we also present a basic implementation of EXT2 filesystem, one of the most used filesystem by Linux users in 90’s years. The main objective of this work is to document a simple and practical source of knowledge about filesystem development over an Unix-like environment.
    [Show full text]
  • Cryptoloop HOWTO
    Cryptoloop HOWTO Ralf Hölzer <[email protected]> 2004−01−15 Revision History Revision 1.2 2004−03−12 Revised by: rh Added information on dm−crypt, updated loop−AES info, added more info on security Revision 1.1 2004−01−24 Revised by: rh Updated information on patching util−linux, Loop−AES, Best Crypt Revision 1.0 2004−01−17 Revised by: rh Initial release, reviewed by TM at LDP. Revision v0.9 2004−01−15 Revised by: rh Updated and converted to DocBook XML. This document explains how to create encrypted file systems using the Cryptoloop functionality. Cryptoloop is part of the CryptoAPI in the 2.6 Linux kernel series. Cryptoloop HOWTO Table of Contents 1. About this document.......................................................................................................................................1 1.1. Copyright and License......................................................................................................................1 1.2. Disclaimer.........................................................................................................................................1 1.3. Credits / Contributors........................................................................................................................1 1.4. Feedback...........................................................................................................................................2 2. Introduction.....................................................................................................................................................3
    [Show full text]