Your SlideShare is downloading. ×

Embedding Linux

631

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
631
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
27
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Embedding Linux David Woodhouse Red Hat, Inc OLS 2002
  • 2. 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
  • 3. 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
  • 4. 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.
  • 5. 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.
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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)
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. Conclusion
    • There’s a lot more work to be done in these area
  • 17.  
  • 18.  

×