• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Embedding Linux

Embedding Linux






Total Views
Views on SlideShare
Embed Views



1 Embed 1

http://www.slideshare.net 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Embedding Linux Embedding Linux Presentation Transcript

    • Embedding Linux David Woodhouse Red Hat, Inc OLS 2002
    • Introduction
      • Linux for embedded system area
        • Overview of application currently being used
        • New application for which development is in progress
        • Requirement & problems unique to such embedded applications
      • Table of contents
        • Current situation of Linux
        • Scaling down Linux kernel
        • uClinux
        • Low fat libraries & Utilities
        • Power management
        • Hot plug capabilities
        • Storage
    • Current Situation of Linux
      • Characteristics of Embedded Systems
        • Limited battery capacity
        • Limited Storage – small flash memory
        • Small display of touch screen
      • Why Linux?
        • Cost per unit !
      • Motivate new research area
        • power management
        • flash storage
        • code size reduction
        • new user interface
      PC Embedded System Enterprise System
    • Scaling down Linux kernel
      • Linux kernel size
        • gzipped tarball size increased from 7301B(v0.01) to 32MB(v2.5.12)
          • largely for new architecture, subsystem, device driver that is conditional part
        • Pure kernel size nearly doubled v2.0->v2.4
          • Not conditional code
        • No visible work for scaling down!!!
      • Candidates for further kernel size reduction
        • networking part
        • code part for block device support
          • significant size saving is possible
          • But complicated task : VFS, VM system, etc.
    • uClinux
      • port of Linux to microcontroller without MMU
        • MMU is prime candidate for removal : Single user mode is sufficient for most embedded systems
      • “ flat” format binary
        • new binary format of uClinux
        • enables drastic rearrangement for loading user space programs
          • all user process shared single address space
          • PIC for data & text segment
      • Supported Platforms
        • Motorola m68k-based CPUS, ARM, Axis’ ETRAX, Intel i960, etc.
    • Low fat library & Utilities
      • Libraries for small footprint
        • Linux libc5 : maintained version of old GNU libc 1.07.4 branch
        • uClibc : uClinux version of libc with MMU support
          • http://www.uclibc.org
          • supprots ARM, MIPS, PowerPC, Hitachi Super-H, etc.
        • diet libc : even better code size reduction then uClibc
          • far more routines are rewritten
          • http://www.fefe.de/dietlibc
      • Multifunction binaries
        • Binaries which can replace a large number of standard utils (cat, mv, cp, ln, …)
        • BusyBox for uClibc & glibc : http://www.busybox.net
        • embutils for diet libc : http://www.fefe.de/embutils
    • Power Managements
      • Suspended Mode
        • all circuit except the RAM can be disabled
        • CPU can be placed into a low-power state or evenly can be shutdown
          • when shutdown, single 32 bit address is still alive that contains return address
          • special interrupt can wake up CPU
    • Power Management
      • Frequency Scaling
        • CPU consume less power at slower speed
        • Basic support is present in the 2.4 version for ARM architecture
          • ARM Integrator, SA1100, SA1110
          • Various Intel IA32 clone architecture
          • CPUFreq supports for AMD PowerNow & VIA Cyrix Longhaul Tech.
          • Intel SpeedStep support is lagging far behind the rest
        • Not Yet Implemented but planned
          • on-shot timer to set up a wake-up time instead of fixed-frequency timer interrupt
    • Hotplug capabilities
      • PCMCIA code rewriting is in progress
      • Basic support for dynamic addtion & removal of PCI device is in Linux kernel
        • support physical insertion, removal, probing, & notification of driver
        • device driver must be upgraded to the New PCI driver API
    • Hotplug capabilities
      • One severe problem of PCI Hotplug code
        • address space assignment problem for newly-inserted cards
          • physical address space for PCI device is limited
          • currently system reserve some address space for each PCI bus
          • If multiple PCI busses are present, repeated insertion & removal of PCI device on different bus will cause resource range fragmentation
        • expected solution
          • New PCI driver API for moving BARs of device
          • Interrupt disabling or stopping HW itself during relocation
    • Storage
      • Distinguishing feature of embedded storage
        • Storage requirement in embedded system area is much different from conventional one
          • persistent storage, low power consumption, relatively low cost, etc.
          • In most cases, flash memory is the only solution
      • NOR flash
        • can be connected directly to the CPU’s address & data buses
        • reading is treated as ROM
        • writing is done in block units
          • large erase block(64KB-128KB)
    • Storage
      • NAND flash
        • cannot access directly
        • data, address, commands are exchanged over a single 8-bit bus
          • reading, writing is performed in command mode
        • smaller erase block (around 8KB) & each block is subdivided into pages of typically 512B
        • cheaper, higher production tolerance than NOR flash
          • low bit error & bad erase block rate
    • Storage
      • Difficulties in using flash
        • Need “wear leveling”
          • to ensure that the block erases are evenly distributed over the entire range of the chips
          • use of traditional filesystem is not appropriate
        • Larger block size than traditional block device
          • Needs a form of “pseudo filesystem” layer that emulate device with small block size
      • Need New Approach!!!
        • JFFS : operate directly on flash memory itself
    • Storage
      • XIP : Execute in place
        • Using data directly from the flash medium by entering pages of the flash chip directly into the page tables
        • Can only use NOR flash & currently is not implemented in Linux
        • XIP and compression are mutually exclusive
        • effective option in situations where low power consumption is extremely important
    • Storage
      • Problems in using XIP
        • Driver must ensure that flash is in read mode
          • When using MMU, it is not possible!!!
        • Solution?
          • scheduling must be disabled when chip is not in read mode - Not feasible
          • every mapping of a flash page to user space must be found - Feasible but needs reverse mappings of physical addresses to virtual addresses
        • Need new filesystem that support XIP effectively
    • Conclusion
      • There’s a lot more work to be done in these area