agnostic device drivers

Download Agnostic Device Drivers

Post on 29-Nov-2014

1.370 views

Category:

Technology

3 download

Embed Size (px)

DESCRIPTION

 

TRANSCRIPT

  • 1. Agnostic Device Drivers ( ADD ) Concept, Design, and Implementation of a Slimline Boot Firmware for Linux on Power Architecture IBM Deutschland Entwicklung GmbH Schoenaicherstr. 220 71032 Boeblingen
  • 2. Contents
    • Open Firmware Standard
    • Existing Hardware Abstraction Concepts
    • Agnostic Device Drivers (ADD)
    • Further Opportunities
  • 3. Is Hardware Abstraction necessary?
  • 4. Open Firmware Standard
    • IEEE Standard IEEE Std. 1275-1994 Standard for Boot (Initialization Configuration) Firmware
      • Device Interface
      • User Interface
      • Client Interface
      • Device-Tree
  • 5. Existing Hardware Abstraction Concepts (based on Open Firmware) Common Hardware Reference Platform: Apple:
  • 6. Comparison - - High-Level Language Facilities: -- - Packaging: +/- - Flexibility: ++ - Performance: Platform Expert RTAS
  • 7. Agnostic Device Drivers (ADD) Concept and Basics
  • 8. Agnostic Device Drivers (ADD) Packaging Options
    • 1: ADD byte-code program taken from Device-Tree
      • Packaged with the Firmware Code.
      • Additional Device-Tree properties can include control or execution information.
    • 2: ADD byte-code program inserted during run-time (via user transaction)
      • Fast development of ADD byte-code programs.
      • Flexible packaging.
  • 9. Agnostic Device Drivers (ADD) Virtual Machine
    • Front-End: Loads Byte-Code (from different sources)
    • Virtual Machine: Executes ADD Byte-Code
    • Back-End: Implements I2C and GPIO Binding to the Operating System
  • 10. Agnostic Device Drivers (ADD) Functionality
    • Small footprint virtual machine
    • Controlling of low-bandwidth devices (e.g. I2C or GPIO) is possible
    • Controlling of the policy and the logic of a device is possible
      • Control Structures
      • Defining Words
    • Extended Debug Facilities
      • Virtual Machine runs in hosted mode
      • Virtual Machine runs as kernel thread (root user can interrupt it)
      • I2C Drivers can debugged via I2C Emulation Host Adapter
      • Rebooting during development is not necessary
      • Single execution is not difficult to implement
  • 11. Agnostic Device Drivers (ADD) Summary ++ ++ ++ ++ Agnostic Device Drivers - - High-Level Language Facilities: -- - Packaging: - - Flexibility: ++ - Performance: Platform Expert RTAS
  • 12.
    • Questions ???
  • 13. Further Opportunities
    • Real-Time / Performance
      • ADD is an asynchronous interface / hardware abstraction.
      • Functionality can implemented as primitive (for real-time applications).
    • Scheduling
      • Scheduling (once, every 5 sec., etc.) can controlled via a Device-Tree property.
      • Thread Support is not difficult to implement (instruction pointer and token-table pointer must saved).
    • Multi-OS
      • Only vendor token-table entries changed.
    • ADD Virtual Machine can integrated into the firmware
      • ADD driver could then used in the firmware and the operating system.
    • Extended Debug Facilities
      • Realizes fast program development and debugging.
  • 14. Agnostic Device Drivers (ADD) Example: Byte Code
  • 15. Agnostic Device Drivers (ADD) Example: Linux Kernel I2C Interface
    • I2C algorithm driver used by the I2C bus driver to talk to the I2C bus.
    • I2C chip driver controls the process of talking to an individual I2C device that lives on an I2C bus.
  • 16. Overview of available Options CHRP (Common Hardware Reference Platform)
    • Based on Open Firmware
    • RTAS (Run-Time Abstraction Service) Hides machine dependent operations behind a machine independent interface, which the operating system can call synchronous.
    • System Firmware = LLFW + Open Firmware + RTAS
  • 17. Overview of available Options RPA (RISC Platform Architecture)
    • Based on CHRP
    • Hypervisor
      • partitions machine resources
      • enables multiple operating systems
      • space for hardware dependent patches
      • only one Hypervisor instance exits for all operating systems
    • Partition Firmware = Open Firmware + RTAS
  • 18. LinuxBIOS
  • 19. OpenBIOS
    • Maintainer Stefan Reinauer and Patrick Mauritz
    • Main Goal To get a 100% compliant Open Firmware boot firmware.
    • Current Function OpenBIOS could be executed under a boot manager or LinuxBIOS.
    • File System Support Support adopted from Grub and libhfs.
    • PPC Support Rudimentary available from the Mac-On-Linux project.
  • 20. Complete Boot Process - Phase 1
  • 21. Complete Boot Process - Phase 2
  • 22. Complete Boot Process - Phase 3