DOCSLIB.ORG

Implantación De Linux Sobre Microcontroladores

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Embedded Linux system development Embedded Linux system development DSI Embedded Linux Free Electrons Developers © Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Latest update: March 14, 2018. Document updates and sources: http://free-electrons.com/doc/training/embedded-linux Corrections, suggestions, contributions and translations are welcome! DSI - FCEIA http://dsi.fceia.unr.edu.ar 1/263 Derechos de copia © Copyright 2018, Luciano Diamand Licencia: Creative Commons Attribution - Share Alike 3.0 http://creativecommons.org/licenses/by-sa/3.0/legalcode Ud es libre de: I copiar, distribuir, mostrar y realizar el trabajo I hacer trabajos derivados I hacer uso comercial del trabajo Bajo las siguientes condiciones: I Atribuci´on. Debes darle el cr´editoal autor original. I Compartir por igual. Si altera, transforma o construye sobre este trabajo, usted puede distribuir el trabajo resultante solamente bajo una licencia id´enticaa ´esta. I Para cualquier reutilizaci´ono distribuci´on,debe dejar claro a otros los t´erminos de la licencia de este trabajo. I Se puede renunciar a cualquiera de estas condiciones si usted consigue el permiso del titular de los derechos de autor. El uso justo y otros derechos no se ven afectados por lo anterior. DSI - FCEIA http://dsi.fceia.unr.edu.ar 2/263 Hiperv´ınculosen el documento Hay muchos hiperv´ınculosen el documento I Hiperv´ıncluosregulares: http://kernel.org/ I Enlaces a la documentaci´ondel Kernel: Documentation/kmemcheck.txt I Enlaces a los archivos fuente y directorios del kernel: drivers/input include/linux/fb.h I Enlaces a declaraciones, definiciones e instancias de los simbolos del kernel (funciones, tipos, datos, estructuras): platform_get_irq() GFP_KERNEL struct file_operations DSI - FCEIA http://dsi.fceia.unr.edu.ar 3/263 Introducci´ona Linux Embebido Introducci´ona DSI Linux Embebido Embedded Linux Developers Free Electrons © Copyright 2004-2018, Free Electrons. Creative Commons BY-SA 3.0 license. Corrections, suggestions, contributions and translations are welcome! DSI - FCEIA http://dsi.fceia.unr.edu.ar 4/263 Nacimiento del software libre I 1983, Richard Stallman, proyecto GNU y el concepto de software libre. Comienza el desarrollo de gcc, gdb, glibc y otras herramientas importantes I 1991, Linus Torvalds, proyecto Linux kernel, un nucleo de sistema operativo similar a Unix. Junto con el software GNU y otros componentes de c´odigoabierto: forman un sistema operativo completo GNU/Linux I 1995, Linux es m´aspopular en sistemas servidor I 2000, Linux es m´aspopular en sistemas embebidos I 2008, Linux es m´aspopular en dispositivos m´oviles I 2010, Linux es m´aspopular en tel´efonos DSI - FCEIA http://dsi.fceia.unr.edu.ar 5/263 >Software libre? I Un programa es considerado libre cuando su licencia ofrece a todos sus usuarios las siguientes cuatro libertades I Libertad de ejecutar el Sofrware para cualquier prop´osito I Libertad de estudiar el Software y modificarlo I Liberatd de redistribuir copias I Libertad de distribuir copias de versiones modificadas I Estas libertades estan concedidas para uso tanto comercial como no-comercial I Implican la disponibilidad del c´odigofuente, el Software puede ser modificado y distribuido a los clientes I Una opci´oninteresante para los sistemas embebidos! DSI - FCEIA http://dsi.fceia.unr.edu.ar 6/263 >Qu´ees Linux embebido? Linux embebido es el uso del kernel de Linux y varios componentes open-source en sistemas embebidos DSI - FCEIA http://dsi.fceia.unr.edu.ar 7/263 Introducci´ona Linux Embebido Ventajas de Linux y open-source para sistemas embebidos DSI - FCEIA http://dsi.fceia.unr.edu.ar 8/263 Reutilizaci´onde componentes I La principal ventaja de Linux y open-source en sistemas embebidos es la habilidad de reutilizar componentes I El ecosistema de open-source ya provee de varios componentes para caracter´ısticasestandares, desde soporte de Hardware hasta protocolos, pasando por multimedia, gr´aficos, bibliotecas criptogr´aficas,etc. I Tan pronto como un dispositivo Hardware, o un protocolo, o una caracter´ısticase torna conocida, existen varias chances de tener un componente open-source que lo soporte. I Permite dise~nar de forma r´apiday desarrollar productos complejos, basados en componentes existentes. I No es necesario redesarrollar otro kernel de sistema operativo, una pila TCP/IP, una pila USB u otra biblioteca gr´afica. I Permite enfocarce en el valor agregado del producto. DSI - FCEIA http://dsi.fceia.unr.edu.ar 9/263 Bajo costo I El Software libre puede ser duplicado en la cantidad de dispositivos que se quiera, libre de cargos. I Si su sistema embebido utiliza solo Software libre, se puede reducir los costos de licencias de Software a cero. Incluso, las herramients de desarrollo son libres, a menos que se elija una versi´onde Linux embebido comercial. I Permite tener un mayor presupuesto para el Hardware o para incrementar las habilidades y conocimiento de la compan´ıa DSI - FCEIA http://dsi.fceia.unr.edu.ar 10/263 Control total I Con c´odigoabierto, disponemos del c´odigofuente de todos los componentes del sistema I Permite modificaciones ilimitadas, cambios, ajustes, depuraci´on,optimizaci´on,por un per´ıodo de tiempo ilimitado I Sin una dependencia "bloqueante" de un vendedor externo I Componentes que no sean de c´odigoabierto se deben evitar cuando el sistema se dise~na y desarrolla I Permite tener un control total sobre el Software que forma parte del sistema DSI - FCEIA http://dsi.fceia.unr.edu.ar 11/263 Calidad I Varios componentes de c´odigoabierto son ampliamente utilizados en millones de sistemas I Generalmente son de mayor calidad que los desarrollos in-house o incluso de los vendedores propietarios I Por supuesto, no todos los componentes de c´odigoabierto son de buena calidad, pero los m´asampliamente utilizados los son. I Permite dise~nar su sistema con componentes fundacionales de alta calidad DSI - FCEIA http://dsi.fceia.unr.edu.ar 12/263 Facilita la prueba de nuevas caracteristicas I Dado la disponibilidad del c´odigoabierto, es simple obtener una copia del Software para evaluarlo I Permite de forma simple estudiar las opciones mientras se est´a decidiendo I Mucho m´assimple que la compra y procesos de demostraci´on necesitan con la mayor´ıade los productos propietarios I Permiten explorar de forma simple nuevas posibilidades y soluciones DSI - FCEIA http://dsi.fceia.unr.edu.ar 13/263 Soporte de la comunidad I Los componentes de Software de c´odigoabierto son desarrollados por comunidades de desarrolladores y usuarios I Esta comunidad puede proveer soporte de alta calidad: se puede contactar directamente a los desarrolladores principales del componente que se est´ausando. La probabilidad de obtener una respuesta no depende de la compan´ıapara la que trabajemos. I En general mejor que el soporte tradicional, pero es necesario entender como funciona la comunidad para hacer un uso correcto de las posibilidades de soporte I Permite acelerar la resoluci´onde problemas cuando se est´edesarrollando el sistema DSI - FCEIA http://dsi.fceia.unr.edu.ar 14/263 Formando parte de la comunidad I La posibilidad de formar parte de la comunidad de desarrollo de algunos de los componentes utilizados en sistemas embebidos: reporte de fallas, prueba de nuevas versiones y caracter´ısticas,parches que corrigen errores o agregan nuevas caracter´ısticas,etc. I La mayor´ıadel tiempo, los componentes de c´odigoabierto no son el n´ucleode valor del producto: es interes de todos contribuir al mismo I Para los ingenieros: una forma muy motivante de ser reconocido fuera de la compan´ıa,comunicarse con otros en el mismo campo, la oportunidad de nuevas posibilidades, etc. I Para los gerentes: factor de motivaci´on para los ingenieros, permite a la compan´ıaser reconocida en la comunidad de c´odigoabierto y por lo tanto obtener soporte de forma m´as simple y ser m´asatractivo para los desarrolladores de c´odigo abierto DSI - FCEIA http://dsi.fceia.unr.edu.ar 15/263 Introducci´ona Linux Embebido Algunos ejemplos de sistemas embebidos ejecutando Linux DSI - FCEIA http://dsi.fceia.unr.edu.ar 16/263 Ruters personales DSI - FCEIA http://dsi.fceia.unr.edu.ar 17/263 Televisi´on DSI - FCEIA http://dsi.fceia.unr.edu.ar 18/263 Terminales de punto de venta DSI - FCEIA http://dsi.fceia.unr.edu.ar 19/263 Maquinas de corte Laser DSI - FCEIA http://dsi.fceia.unr.edu.ar 20/263 Maquina de Viticultura DSI - FCEIA http://dsi.fceia.unr.edu.ar 21/263 Introducci´ona Linux Embebido Hardware para sistemas embebidos en Linux DSI - FCEIA http://dsi.fceia.unr.edu.ar 22/263 Procesador y arquitectura (1) I El kernel de Linux y la mayor´ıade otros componentes dependientes de la arquitectura soportan un amplio rango de arquitecturas de 32 y 64 bits I x86 y x86-64, como se encuentran en plataformas PC, pero tambi´ensistemas embebidos (multimedia, industrial) I ARM, con miles de diferentes SoC (multimedia, industrial) I PowerPC (principalmente aplicaciones en tiempo real e industriales) I MIPS (principalmente para aplicaciones de red) I SuperH (principalmente aplicaciones multimedia) I Blackfin (arquitectura DSP) I Microblaze (soft-core para FGPA de Xilinx) I Coldfire, SCore, Tile, Xtensa, Cris, FRV, AVR32, M32R DSI - FCEIA http://dsi.fceia.unr.edu.ar 23/263 Procesador y arquitectura (2) I Ambas arquitecturas, MMU y no-MMU son soportadas, aunque la arquitectura no-MMU tiene algunas limitaciones. I Linux no est´adise~nadopara microcontroladores peque~nos. I Salvo el juego de herraminetas, el cargador de inicio y el kernel, todos los otros componentes generalmente son independientes de la arquitectura DSI - FCEIA http://dsi.fceia.unr.edu.ar 24/263 RAM y almacenamiento I RAM: un sistema b´asicocon Linux puede funcionar con 8 MB de RAM, pero un sistema m´asrealista usualmente requiere 32 MB de RAM.
Recommended publications
  • Chapter 3. Booting Operating Systems

    Chapter 3. Booting Operating Systems

    Chapter 3. Booting Operating Systems Abstract: Chapter 3 provides a complete coverage on operating systems booting. It explains the booting principle and the booting sequence of various kinds of bootable devices. These include booting from floppy disk, hard disk, CDROM and USB drives. Instead of writing a customized booter to boot up only MTX, it shows how to develop booter programs to boot up real operating systems, such as Linux, from a variety of bootable devices. In particular, it shows how to boot up generic Linux bzImage kernels with initial ramdisk support. It is shown that the hard disk and CDROM booters developed in this book are comparable to GRUB and isolinux in performance. In addition, it demonstrates the booter programs by sample systems. 3.1. Booting Booting, which is short for bootstrap, refers to the process of loading an operating system image into computer memory and starting up the operating system. As such, it is the first step to run an operating system. Despite its importance and widespread interests among computer users, the subject of booting is rarely discussed in operating system books. Information on booting are usually scattered and, in most cases, incomplete. A systematic treatment of the booting process has been lacking. The purpose of this chapter is to try to fill this void. In this chapter, we shall discuss the booting principle and show how to write booter programs to boot up real operating systems. As one might expect, the booting process is highly machine dependent. To be more specific, we shall only consider the booting process of Intel x86 based PCs.
  • Timesys Linux Install HOWTO

    Timesys Linux Install HOWTO

    TimeSys Linux Install HOWTO Trevor Harmon <[email protected]> 2005−04−05 Revision History Revision 1.0 2005−04−05 Revised by: TH first official release This document is a quick−start guide for installing TimeSys Linux on a typical desktop workstation. TimeSys Linux Install HOWTO Table of Contents 1. Introduction.....................................................................................................................................................1 1.1. Background.......................................................................................................................................1 1.2. Copyright and License......................................................................................................................1 1.3. Disclaimer.........................................................................................................................................2 1.4. Feedback...........................................................................................................................................2 2. Requirements...................................................................................................................................................3 3. Install the packages.........................................................................................................................................4 4. Prepare the source directories.......................................................................................................................5 5. Configure
  • Open Source Projects As Incubators of Innovation

    Open Source Projects As Incubators of Innovation

    RESEARCH CONTRIBUTIONS TO ORGANIZATIONAL SOCIOLOGY AND INNOVATION STUDIES / STUTTGARTER BEITRÄGE ZUR ORGANISATIONS- UND INNOVATIONSSOZIOLOGIE SOI Discussion Paper 2017-03 Open Source Projects as Incubators of Innovation From Niche Phenomenon to Integral Part of the Software Industry Jan-Felix Schrape Institute for Social Sciences Organizational Sociology and Innovation Studies Jan-Felix Schrape Open Source Projects as Incubators of Innovation. From Niche Phenomenon to Integral Part of the Software Industry. SOI Discussion Paper 2017-03 University of Stuttgart Institute for Social Sciences Department of Organizational Sociology and Innovation Studies Seidenstr. 36 D-70174 Stuttgart Editor Prof. Dr. Ulrich Dolata Tel.: +49 711 / 685-81001 [email protected] Managing Editor Dr. Jan-Felix Schrape Tel.: +49 711 / 685-81004 [email protected] Research Contributions to Organizational Sociology and Innovation Studies Discussion Paper 2017-03 (May 2017) ISSN 2191-4990 © 2017 by the author(s) Jan-Felix Schrape is senior researcher at the Department of Organizational Sociology and Innovation Studies, University of Stuttgart (Germany). [email protected] Additional downloads from the Department of Organizational Sociology and Innovation Studies at the Institute for Social Sciences (University of Stuttgart) are filed under: http://www.uni-stuttgart.de/soz/oi/publikationen/ Abstract Over the last 20 years, open source development has become an integral part of the software industry and a key component of the innovation strategies of all major IT providers. Against this backdrop, this paper seeks to develop a systematic overview of open source communities and their socio-economic contexts. I begin with a recon- struction of the genesis of open source software projects and their changing relation- ships to established IT companies.
  • Atomicity and Visibility in Tiny Embedded Systems

    Atomicity and Visibility in Tiny Embedded Systems

    Atomicity and Visibility in Tiny Embedded Systems John Regehr Nathan Cooprider David Gay University of Utah, School of Computing Intel Research Berkeley {regehr, coop}@cs.utah.edu [email protected] Abstract bool flag = false; // interrupt handler Visibility is a property of a programming language’s void __vector_5 (void) memory model that determines when values stored by { one concurrent computation become visible to other atomic flag = true; computations. Our work exploits the insight that in } nesC, a C-like language with explicit atomicity, the traditional way of ensuring timely visibility—volatile void wait_for_interrupt(void) variables—can be entirely avoided. This is advan- { tageous because the volatile qualifier is a notorious bool done = false; do { source of programming errors and misunderstandings. atomic if (!flag) done = true; Furthermore, the volatile qualifier hurts performance } while (!done); by inhibiting many more optimizations than are neces- } sary to ensure visibility. In this paper we extend the semantics of nesC’s atomic statements to include a visi- bility guarantee, we show two ways that these semantics Figure 1. nesC code containing a visibility er- can be implemented, and we also show that our better ror implementation has no drawbacks in terms of resource usage. Until now, nesC has left it to programmers to en- 1. Introduction sure visibility by judicious use of C’s volatile qual- ifier. In this paper we investigate the idea of strength- ening nesC’s memory model such that the semantics of The nesC [5] language is a C dialect designed for pro- atomic are augmented with a visibility guarantee. This gramming embedded wireless sensor network nodes.
  • Download This Issue

    Download This Issue

    Editorial Dru Lavigne, Thomas Kunz, François Lefebvre Open is the New Closed: How the Mobile Industry uses Open Source to Further Commercial Agendas Andreas Constantinou Establishing and Engaging an Active Open Source Ecosystem with the BeagleBoard Jason Kridner Low Cost Cellular Networks with OpenBTS David Burgess CRC Mobile Broadcasting F/LOSS Projects François Lefebvre Experiences From the OSSIE Open Source Software Defined Radio Project Carl B. Dietrich, Jeffrey H. Reed, Stephen H. Edwards, Frank E. Kragh The Open Source Mobile Cloud: Delivering Next-Gen Mobile Apps and Systems Hal Steger The State of Free Software in Mobile Devices Startups Bradley M. Kuhn Recent Reports Upcoming Events March Contribute 2010 March 2010 Editorial Dru Lavigne, Thomas Kunz, and François Lefebvre discuss the 3 editorial theme of Mobile. Open is the New Closed: How the Mobile Industry uses Open Source to Further Commercial Agendas Andreas Constantinou, Research Director at VisionMobile, PUBLISHER: examines the many forms that governance models can take and 5 The Open Source how they are used in the mobile industry to tightly control the Business Resource is a roadmap and application of open source projects. monthly publication of the Talent First Network. Establishing and Engaging an Active Open Source Ecosystem with Archives are available at the BeagleBoard the website: Jason Kridner, open platforms principal architect at Texas 9 http://www.osbr.ca Instruments Inc., introduces the BeagleBoard open source community. EDITOR: Low Cost Cellular Networks with OpenBTS Dru Lavigne David Burgess, Co-Founder of The OpenBTS Project, describes 14 [email protected] how an open source release may have saved the project.
  • Operating Systems and Applications for Embedded Systems >>> Toolchains

    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.
  • MINCS - the Container in the Shell (Script)

    MINCS - the Container in the Shell (Script)

    MINCS - The Container in the Shell (script) - Masami Hiramatsu <[email protected]> Tech Lead, Linaro Ltd. Open Source Summit Japan 2017 LEADING COLLABORATION IN THE ARM ECOSYSTEM Who am I... Masami Hiramatsu - Linux kernel kprobes maintainer - Working for Linaro as a Tech Lead LEADING COLLABORATION IN THE ARM ECOSYSTEM Demo # minc top # minc -r /opt/debian/x86_64 # minc -r /opt/debian/arm64 --arch arm64 LEADING COLLABORATION IN THE ARM ECOSYSTEM What Is MINCS? My Personal Fun Project to learn how linux containers work :-) LEADING COLLABORATION IN THE ARM ECOSYSTEM What Is MINCS? Mini Container Shell Scripts (pronounced ‘minks’) - Container engine implementation using POSIX shell scripts - It is small (~60KB, ~2KLOC) (~20KB in minimum) - It can run on busybox - No architecture dependency (* except for qemu/um mode) - No need for special binaries (* except for libcap, just for capsh --exec) - Main Features - Namespaces (Mount, PID, User, UTS, Net*) - Cgroups (CPU, Memory) - Capabilities - Overlay filesystem - Qemu cross-arch/system emulation - User-mode-linux - Image importing from dockerhub And all are done by CLI commands :-) LEADING COLLABORATION IN THE ARM ECOSYSTEM Why Shell Script? That is my favorite language :-) - Easy to understand for *nix administrators - Just a bunch of commands - Easy to modify - Good for prototyping - Easy to deploy - No architecture dependencies - Very small - Able to run on busybox (+ libcap is perfect) LEADING COLLABORATION IN THE ARM ECOSYSTEM MINCS Use-Cases For Learning - Understand how containers work For Development - Prepare isolated (cross-)build environment For Testing - Test new applications in isolated environment - Test new kernel features on qemu using local tools For products? - Maybe good for embedded devices which has small resources LEADING COLLABORATION IN THE ARM ECOSYSTEM What Is A Linux Container? There are many linux container engines - Docker, LXC, rkt, runc, ..
  • LVC20-108 Arm64 Linux Kernel Architecture Update

    LVC20-108 Arm64 Linux Kernel Architecture Update

    Arm64 Linux Kernel architecture update Matteo Carlini Director, Software Technology Management Arm – Open Source Software A-profile Architecture new feature names! https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools/feature-names-for-a-profile A-profile features: arm64 kernel support table https://developer.arm.com/tools-and-software/open-source-software/linux-kernel/architecture-and-kvm-enablement A-class architecture kernel enablement – Mar 20 TTS2UXN A64ISA AA32HPD PAUTH CNTS PMU S2FW FHM TTPBHA C B Trace LSE LSE IESB LSMAOC Debug SHA PMU RDMA CompNum JSconv S-EL2 SM SM TTCNP TTST VMID16 HPD v8.3 DIT SHA UAO v8.1 v8.2 RAS v8.4 IDST RCPC CCIDX DotProd ATS1E1 LOR VHE DFE CondM TTRe NV RCPC RAS LP16 m PAN TTHM MPAM AMU TTL NV Debug LVA TLBI VPIPT LPA DCPOP EVT DoPD GTG ECV MTPMU ETS SVE2 SPE SpecRest MPAM CTSS PMU PredInv PAuth2/ Future FGT FPAC architectures v8.0 RNG BT v8.5 v8.6 F64MM DGH DCCVADP MemTag Enablement complete TME EOPD CSEH F32MM TWED Enablement ongoing Enablement TBD SB CMODX I8MM BF16 FRINT CondM AMU N/A – no Kernel impact A-class architecture kernel enablement – Today TTS2UXN A64ISA AA32HPD PAUTH PMU FHM TTPBHA CNTSC S2FWB S-EL2 LSE LSE IESB LSMAOC TTST SHA PMU RDMA CompNum JSconv RAS SM SM TTCNP VMID16 HPD v8.3 DFE DIT SHA UAO TTRem v8.4 v8.1 v8.2 IDST RCPC CCIDX DotProd ATS1E1 LOR VHE Trace CondM NV Debug RCPC RAS LP16 PAN TTHM MPAM AMU Debug LVA NV TLBI TTL VPIPT LPA DCPOP GTG SPE SpecRest ECV MTPMU ETS SVE2 PMU PredInv MPAM CTSS RNG MemTag PAuth2/ Future FGT FPAC architectures v8.0
  • Linux Boot Loaders Compared

    Linux Boot Loaders Compared

    Linux Boot Loaders Compared L.C. Benschop May 29, 2003 Copyright c 2002, 2003, L.C. Benschop, Eindhoven, The Netherlands. Per- mission is granted to make verbatim copies of this document. This is version 1.1 which has some minor corrections. Contents 1 introduction 2 2 How Boot Loaders Work 3 2.1 What BIOS does for us . 3 2.2 Parts of a boot loader . 6 2.2.1 boot sector program . 6 2.2.2 second stage of boot loader . 7 2.2.3 Boot loader installer . 8 2.3 Loading the operating system . 8 2.3.1 Loading the Linux kernel . 8 2.3.2 Chain loading . 10 2.4 Configuring the boot loader . 10 3 Example Installations 11 3.1 Example root file system and kernel . 11 3.2 Linux Boot Sector . 11 3.3 LILO . 14 3.4 GNU GRUB . 15 3.5 SYSLINUX . 18 3.6 LOADLIN . 19 3.7 Where Can Boot Loaders Live . 21 1 4 RAM Disks 22 4.1 Living without a RAM disk . 22 4.2 RAM disk devices . 23 4.3 Loading a RAM disk at boot time . 24 4.4 The initial RAM disk . 24 5 Making Diskette Images without Diskettes 25 6 Hard Disk Installation 26 7 CD-ROM Installation 29 8 Conclusions 31 1 introduction If you use Linux on a production system, you will only see it a few times a year. If you are a hobbyist who compiles many kernels or who uses many operating systems, you may see it several times per day.
  • Dell EMC Poweredge Systems Running Red Hat Enterprise Linux 7 Release Notes Notes, Cautions, and Warnings

    Dell EMC Poweredge Systems Running Red Hat Enterprise Linux 7 Release Notes Notes, Cautions, and Warnings

    Dell EMC PowerEdge Systems Running Red Hat Enterprise Linux 7 Release Notes Notes, cautions, and warnings NOTE: A NOTE indicates important information that helps you make better use of your product. CAUTION: A CAUTION indicates either potential damage to hardware or loss of data and tells you how to avoid the problem. WARNING: A WARNING indicates a potential for property damage, personal injury, or death. © 2014 - 2019 Dell Inc. or its subsidiaries. All rights reserved. Dell, EMC, and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be trademarks of their respective owners. 2019 - 03 Rev. A15 Contents 1 Overview........................................................................................................................................................6 System configuration requirements................................................................................................................................. 6 Memory......................................................................................................................................................................... 6 Installation and upgrade instructions............................................................................................................................... 6 2 Known issues—To be fixed in future releases.................................................................................................7 Unable to create or modify namespace for NVDIMM..................................................................................................
  • System Size BOF

    System Size BOF

    ELC 2009 System Size BOF Michael Opdenacker Free Electrons 1 Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http//free-electrons.com Rights to copy © Copyright 2004-2009, Free Electrons [email protected] Document sources: http://free-electrons.com/pub/conferences/2009/elc/ Updates on size reduction techniques can be found on http://free-electrons.com/docs/optimizations/ Attribution ± ShareAlike 3.0 You are free to copy, distribute, display, and perform the work Corrections, suggestions, to make derivative works contributions and translations are welcome! to make commercial use of the work Under the following conditions Latest update: Apr 28, 2009 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 2 Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http//free-electrons.com 24 slides... To avoid a tragic increase in the size of your system. 3 Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support. http//free-electrons.com Why system size matters Because Linux wouldn©t fit otherwise To leave more space for user data (media players) To keep things easier to maintain Lighter code is faster to boot We should stop size growth because we don©t want to force people to use old kernels and old software.
  • The Linux Device File-System

    The Linux Device File-System

    The Linux Device File-System Richard Gooch EMC Corporation [email protected] Abstract 1 Introduction All Unix systems provide access to hardware via de- vice drivers. These drivers need to provide entry points for user-space applications and system tools to access the hardware. Following the \everything is a file” philosophy of Unix, these entry points are ex- posed in the file name-space, and are called \device The Device File-System (devfs) provides a power- special files” or \device nodes". ful new device management mechanism for Linux. Unlike other existing and proposed device manage- This paper discusses how these device nodes are cre- ment schemes, it is powerful, flexible, scalable and ated and managed in conventional Unix systems and efficient. the limitations this scheme imposes. An alternative mechanism is then presented. It is an alternative to conventional disc-based char- acter and block special devices. Kernel device drivers can register devices by name rather than de- vice numbers, and these device entries will appear in the file-system automatically. 1.1 Device numbers Devfs provides an immediate benefit to system ad- ministrators, as it implements a device naming scheme which is more convenient for large systems Conventional Unix systems have the concept of a (providing a topology-based name-space) and small \device number". Each instance of a driver and systems (via a device-class based name-space) alike. hardware component is assigned a unique device number. Within the kernel, this device number is Device driver authors can benefit from devfs by used to refer to the hardware and driver instance.